System and method for configuring a programmable hardware instrument to perform measurement functions utilizing estimation of the hardware implementation and management of hardware resources

ABSTRACT

A computer-implemented system and method for generating a hardware implementation of graphical code. The method may operate to configure an instrument to perform measurement functions, wherein the instrument includes a programmable hardware element. The method comprises first creating a graphical program, wherein the graphical program may implement a measurement function. A portion of the graphical program may optionally be compiled into machine code for execution by a CPU, and another portion of the graphical program may be converted into a hardware implementation on a programmable hardware element. The programmable hardware element is configured utilizing a hardware description to produce a configured hardware element. The configured hardware element thus implements a hardware implementation of the second portion of the graphical program. During generation of the hardware implementation, the computer system may operate to estimate and/or display one or more of size and cost of a hardware implementation of the graphical program. In one embodiment, the graphical program manipulates one or more hardware resources of an instrument, and an indication of usage of the one or more hardware resources are displayed during creation of the graphical program. Probes may also be inserted into the graphical program, wherein corresponding probe elements are placed in the hardware implementation to implement the probe function.

This application is a continuation-in-part of U.S. patent applicationSer. No. 08/912,427 titled “System and Method for Configuring anInstrument to Perform Measurement Functions Utilizing Conversion ofGraphical Programs into Hardware Implementations”, filed on Aug. 18,1997, whose inventors are Jeffrey L. Kodosky, Hugo Andrade, Brian KeithOdom and Cary Paul Butler, which is now U.S. Pat. No. 6,219,628.

FIELD OF THE INVENTION

The present invention relates to graphical programming, and inparticular to a system and method for converting a graphical programinto a hardware implementation. The present invention further relates toa system and method for configuring an instrument to perform measurementfunctions, wherein the instrument includes a programmable hardwareelement

DESCRIPTION OF THE RELATED ART

Traditionally, high level text-based programming languages have beenused by programmers in writing applications programs. Many differenthigh level programming languages exist, including BASIC, C, FORTRAN,Pascal, COBOL, ADA, APL, etc. Programs written in these high levellanguages are translated to the machine language level by translatorsknown as compilers or interpreters. The high level programming languagesin this level, as well as the assembly language level, are referred toas text-based programming environments.

Increasingly computers are required to be used and programmed by thosewho are not highly trained in computer programming techniques. Whentraditional text-based programming environments are used, the user'sprogramming skills and ability to interact with the computer systemoften become a limiting factor in the achievement of optimal utilizationof the computer system.

There are numerous subtle complexities which a user must master beforehe can efficiently program a computer system in a text-basedenvironment. The task of programming a computer system to model orimplement a process often is further complicated by the fact that asequence of mathematical formulas, mathematical steps or otherprocedures customarily used to conceptually model a process often doesnot closely correspond to the traditional text-based programmingtechniques used to program a computer system to model such a process. Inother words, the requirement that a user program in a text-basedprogramming environment places a level of abstraction between the user'sconceptualization of the solution and the implementation of a methodthat accomplishes this solution in a computer program. Thus, a useroften must substantially master different skills in order to bothconceptually model a system and then to program a computer to model thatsystem. Since a user often is not fully proficient in techniques forprogramming a computer system in a text-based environment to implementhis model, the efficiency with which the computer system can be utilizedto perform such modeling often is reduced.

Examples of fields in which computer systems are employed to modeland/or control physical systems are the fields of instrumentation,process control, industrial automation, and simulation. Computermodeling or control of devices such as instruments or industrialautomation hardware has become increasingly desirable in view of theincreasing complexity and variety of instruments and devices availablefor use. However, due to the wide variety of possible testing/controlsituations and environments, and also the wide array of instruments ordevices available, it is often necessary for a user to develop a programto control a desired system. As discussed above, computer programs usedto control such systems had to be written in conventional text-basedprogramming languages such as, for example, assembly language, C,FORTRAN, BASIC, or Pascal. Traditional users of these systems, however,often were not highly trained in programming techniques and, inaddition, traditional text-based programming languages were notsufficiently intuitive to allow users to use these languages withouttraining. Therefore, implementation of such systems frequently requiredthe involvement of a programmer to write software for control andanalysis of instrumentation or industrial automation data. Thus,development and maintenance of the software elements in these systemsoften proved to be difficult.

U.S. Pat. Nos. 4,901,221; 4,914,568; 5,291,587; 5,301,301; and5,301,336; among others, to Kodosky et al disclose a graphical systemand method for modeling a process, i.e., a graphical programmingenvironment which enables a user to easily and intuitively model aprocess. The graphical programming environment disclosed in Kodosky etal can be considered the highest and most intuitive way in which tointeract with a computer. A graphically based programming environmentcan be represented at a level above text-based high level programminglanguages such as C, Pascal, etc. The method disclosed in Kodosky et alallows a user to construct a diagram using a block diagram editor, suchthat the diagram created graphically displays a procedure or method foraccomplishing a certain result, such as manipulating one or more inputvariables to produce one or more output variables. In response to theuser constructing a data flow diagram or graphical program using thebock diagram editor, data structures are automatically constructed whichcharacterize an execution procedure which corresponds to the displayedprocedure. The graphical program may be compiled or interpreted by acomputer. Therefore, a user can create a computer program solely byusing a graphically based programming environment. This graphicallybased programming environment may be used for creating virtualinstrumentation systems, industrial automation systems, modelingprocesses, and simulation, as well as for any type of generalprogramming.

Therefore, Kodosky et al teaches a graphical programming environmentwherein a user places or manipulates icons in a block diagram using ablock diagram editor to create a data flow “program.” A graphicalprogram for controlling or modeling devices, such as instruments,processes or industrial automation hardware, may be referred to as avirtual instrument (VI). In creating a virtual instrument, a user maycreate a front panel or user interface panel. The front panel includesvarious user interface elements or front panel objects, such as controlsor indicators, that represent or display the respective input and outputthat will be used by the graphical program or VI, and may include othericons which represent devices being controlled. The front panel may becomprised in a single window of user interface elements, or may comprisea plurality of individual windows each having a user interface element,wherein the individual windows may optionally be tiled together. Whenthe controls and indicators are created in the front panel,corresponding icons or terminals may be automatically created in theblock diagram by the block diagram editor. Alternatively, the user canplace terminal icons in the block diagram which may cause the display ofcorresponding front panel objects in the front panel, either at edittime or later at run time. As another example, the front panel objectsmay be embedded in the block diagram.

During creation of the graphical program, the user may selects variousfunction nodes or icons that accomplish his desired result and connectsthe function nodes together. For example, the function nodes may beconnected in a data flow or control flow format. The function nodes maybe connected between the terminals of the respective controls andindicators. Thus the user may create or assemble a data flow program,referred to as a block diagram, representing the graphical data flowwhich accomplishes his desired process. The assembled graphical programmay then be compiled or interpreted to produce machine language thataccomplishes the desired method or process as shown in the blockdiagram.

A user may input data to a virtual instrument using front panelcontrols. This input data may propagate through the data flow blockdiagram or graphical program and appear as changes on the outputindicators. In an instrumentation application, the front panel can beanalogized to the front panel of an instrument. In an industrialautomation application the front panel can be analogized to the MMI (ManMachine Interface) of a device. The user may adjust the controls on thefront panel to affect the input and view the output on the respectiveindicators. Alternatively, the front panel may be used merely to viewthe input and output, and the input may not be interactively manipulableby the user during program execution.

Thus, graphical programming has become a powerful tool available toprogrammers. Graphical programming environments such as the NationalInstruments LabVIEW product have become very popular. Tools such asLabVIEW have greatly increased the productivity of programmers, andincreasing numbers of programmers are using graphical programmingenvironments to develop their software applications. In particular,graphical programming tools are being used for test and measurement,data acquisition, process control, man machine interface (MMI),supervisory control and data acquisition (SCADA) applications,simulation, and machine vision applications, among others.

A primary goal of graphical programming, including virtualinstrumentation, is to provide the user the maximum amount offlexibility to create his/her own applications and/or define his/her owninstrument functionality. In this regard, it is desirable to extend thelevel at which the user is able to program a device, e.g., extend thelevel at which a user of instrumentation or industrial automationhardware is able to program an instrument. The evolution of the levelsat which the user has been able to program an instrument is essentiallyas follows.

-   -   1. User level software (LabVIEW, LabWindows CVI, Visual Basic,        etc.)    -   2. Kernel level software    -   3. Auxiliary kernel level software (a second kernel running        along side the main OS, e.g., InTime, VentureCom, etc.)    -   4. Embedded kernel level software    -   5. Hardware level software (FPGA—the present patent application)

In general, going down the above list, the user is able to createsoftware applications which provide a more deterministic real-timeresponse. Currently, most programming development tools forinstrumentation or industrial automation provide an interface at level 1above. In general, most users are unable and/or not allowed to programat the kernel level or auxiliary kernel level. The user level softwaretypically takes the form of software tools that can be used to createsoftware which operates at levels 1 and/or 4.

Current instrumentation solutions at level 5 primarily exist asvendor-defined solutions, i.e., vendor created modules. However, itwould be highly desirable to provide the user with the ability todevelop user level software which operates at the hardware level. Moreparticularly, it would be desirable to provide the user with the abilityto develop high level software, such as graphical programs, which canthen be readily converted into hardware level functionality. This wouldprovide the user with the dual benefits of being able to program devicefunctionality at the highest level possible (text-based or graphicalprograms), while also providing the ability to have the created programoperate directly in hardware for increased speed and efficiency.

SUMMARY OF THE INVENTION

The present invention comprises a computer-implemented system and methodfor automatically generating hardware level functionality, e.g.,programmable hardware such as FPGAs or CPLDs, in response to a graphicalprogram created by a user. This provides the user the ability to developor define desired functionality using graphical programming techniques,while enabling the resulting program to operate directly in hardware.

The user first creates a graphical program which performs or representsthe desired functionality. The graphical program may include one or moremodules or a hierarchy of subprograms. In the preferred embodiment, theuser may place various constructs in portions of the graphical programto aid in conversion of these portions into hardware form. As the usercreates or assembles the graphical program on the display, datastructures are automatically created and stored in memory correspondingto the graphical program being created.

The user may then select an option to convert the graphical program intoexecutable form, wherein at least a portion of the graphical program isconverted into a hardware implementation. According to one embodiment ofthe present invention, the user can select which portions of modules (orsub-VIs) are to be translated into hardware form, either during creationof the graphical program or when selecting the option to convert thegraphical program into executable form. Thus the user can select a firstportion of the graphical program, preferably comprising the supervisorycontrol and display portion of the program, to be compiled into machinelanguage for execution on a CPU. The user can select a second portion ofthe graphical program which is desired for hardware implementation.Alternatively, the selection of portions of the graphical program to becompiled for execution by the host CPU or to be provided for hardwareimplementation may be automatically performed by the system.

The portion of the graphical program selected for hardwareimplementation may first be converted to an abstract hardware graph,also referred to as a VDiagram tree. More specifically, the datastructures corresponding to the graphical program may be converted intothe abstract hardware graph or VDiagram tree. Thus the conversion maynot be a one-step process of generating a hardware description directlyfrom graphical program internal data structures, but rather preferablyinvolves the VDiagram intermediate format. The VDiagram tree comprisesdata structures representing the functional objects of the graphicalprogram and the data flow between them. VDiagrams are described indetail below.

The VDiagram tree may be parsed by a back end program module whichgenerates a specific hardware description from the tree, such as a VHDLor EDIF hardware description. The hardware description may thenconverted into a hardware netlist. Netlists for various types ofhardware devices may be created from a hardware description (e.g.,FPGA-specific netlists, CPLD-specific netlists, etc.). As used herein,the term “netlist” comprises various intermediate hardware-specificdescription formats comprising information regarding the particularhardware elements required to implement a hardware design and therelationship among those elements. For example, the back end maygenerate a VHDL file containing a hardware description of the graphicalprogram. An FPGA-specific netlist may then be created from the VHDLfile, wherein the netlist comprises information regarding the variousFPGA components (and the logical relationship among those components)necessary to implement the hardware design described in the VHDL file.

The process of converting a hardware description such as a VHDL fileinto a netlist may be performed by readily available synthesis tools, asis well known in the art. The netlist may then be compiled into ahardware program file (also called a software bit stream) which may beused to program a programmable logic device (PLD) such as an FPGA or aCPLD, or other types of (re)configurable hardware devices. In thepreferred embodiment, the hardware description is converted into an FPGAprogram file.

The step of compiling the resulting netlist into a PLD program filepreferably uses a library of pre-compiled function blocks to aid in thecompilation, as well as hardware target specific information. Thelibrary of pre-compiled function blocks includes netlist libraries forprogrammatic structures, such as for/next loops, while/do loops, casestructures, and sequence structures, among others. This allows the userto program with high-level programming constructs, such as iteration,looping, and case structures, while allowing the resulting program toexecute directly in hardware.

The resulting bit stream is then transferred to a PLD or other(re)configurable hardware device such as an FPGA to produce a programmedhardware device equivalent to the graphical program or block diagram.

The preferred embodiment of the invention comprises a general purposecomputer system which includes a CPU and memory, and an interface cardor device coupled to the computer system which includes programmablehardware or logic, such as an FPGA. The computer system includes agraphical programming system which is used to develop the graphicalprogram. The computer system also includes software according to thepresent invention which is operable to convert the graphical programinto an abstract hardware graph, and then convert the abstract hardwaregraph into a hardware description. The computer system further includesa synthesis tool which is used to compile the hardware description intoa netlist, as well as other tools for converting the netlist into a PLDprogram file for uploading into the PLD. The computer system furtherincludes a library of pre-compiled function blocks according to thepresent invention which are used by the synthesis tool to aid increating the netlist.

As described above, in the preferred embodiment, a user creates agraphical program and then uses the system and method of the presentinvention to convert at least a portion of the graphical program into ahardware description. The hardware description may then be converted toa hardware program which executes on a PLD. The present invention thusextends the traditional model of software development to include thepossibility of running at least a portion of a program on hardwarecreated specifically for the program instead of running the entireprogram on the general-purpose processor.

However, it is noted that the use of the present invention is notlimited to the creation of application programs as described above. Thepresent invention comprises a system and method to create an abstracthardware graph from a graphical program. Various back end programs maybe called to generate disparate types of hardware descriptions from theabstract hardware graph. These hardware descriptions may be used forpurposes other than creating a bit stream for programming a PLD. Forexample, a hardware description may be used in the process of creatingand printing a traditional circuit board which may be produced in massquantities.

It is also noted that various back end programs may be called togenerate software source code, such as C language code, from theabstract hardware graph. As described in detail below, the abstracthardware graph (VDiagram tree) generated by the present inventioncontains information regarding the execution order and data flow of thegraphical program. This information may be used to establish aprocedural order in a traditional programming language. Also, since theexecution order for portions of a graphical program may be inherentlyparallel, the system and method of the present invention are well-suitedfor creating a program in a text-based parallel programming language.

In one embodiment, the target device including the reconfigurablehardware or PLD being programmed comprises a measurement device or cardin the computer system, such as a data acquisition device or card, aGPIB interface card, a VXI interface card, or other measurement device.In an alternate embodiment, the target device being programmed comprisesan instrument or device connected to the computer, such as through aserial connection. It is noted that the target instrument or devicebeing programmed, which includes a PLD or other (re)configurablehardware element, can take any of various forms, as desired.

Thus the method may operate to configure an instrument to performmeasurement functions, wherein the instrument includes a programmablehardware element. First, the method creates a graphical program, whereinthe graphical program implements a measurement function. The computersystem may then estimate and then optionally display one or more of thesize and cost of a hardware implementation of the graphical program.

In one embodiment, for example where the graphical program implements ameasurement function, the graphical program manipulates one or morehardware resources of the instrument. Examples of hardware resourcesinclude A/D converters, D/A converters, timers, counters, clocks, etc.In this embodiment, creating the graphical program includes displayingan indication of usage, or the status of usage, of the one or morehardware resources during creation of the graphical program.

In another embodiment, the user may insert a probe at a location in thegraphical program, wherein the probe is operable to display datagenerated at the location during execution of the graphical program. Inthis embodiment, the configured hardware element includes the probeelement for implementing probing in the configured hardware element.

It is noted that non real-time clock cycle observations are possible incurrent FPGA's, such as Xilinx FPGAs, without external/explicit hooks.However, explicit probes/probe interfaces on the program of the FPGAallow external visibility and real-time performance.

The method then generates a hardware description based on at least aportion of the graphical program, wherein the hardware descriptiondescribes a hardware implementation of the at least a portion of thegraphical program. The programmable hardware element is then configuredin the instrument utilizing the hardware description to produce aconfigured hardware element, wherein the configured hardware elementimplements a hardware implementation of the at least a portion of thegraphical program. After the hardware element has been configured, thesystem may be executed. During execution, the instrument acquires asignal from an external source, and the programmable hardware element inthe instrument executes to perform the measurement function on thesignal.

BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of the present invention can be obtained when thefollowing detailed description of the preferred embodiment is consideredin conjunction with the following drawings, in which:

FIG. 1 illustrates the conversion of a graphical program to hardware andsoftware implementations;

FIG. 2 illustrates the generation of various types of hardware andsoftware descriptions from a VDiagram tree;

FIG. 3 illustrates the conversion of a graphical program into a hardwaredescription and the use of the hardware description to program an FPGA;

FIG. 4 illustrates the conversion of a graphical program into a softwaresource code description and the compilation and linkage of the sourcecode;

FIG. 5A illustrates an instrumentation control system;

FIG. 5B illustrates an industrial automation system;

FIG. 6 is a block diagram of the instrumentation control system of FIG.5A;

FIGS. 7, 7A and 7B are block diagrams illustrating an interface cardconfigured with programmable hardware according to various embodimentsof the present invention;

FIG. 8 is a flowchart diagram illustrating operation of the preferredembodiment of the invention, including compiling a first portion of thegraphical program into machine language and converting a second portionof the graphical program into a hardware implementation;

FIG. 9 is a more detailed flowchart diagram illustrating creation of agraphical program according to the preferred embodiment;

FIG. 10 is a graphical representation of a VDiagram and the relationshipamong its elements;

FIG. 11 is an example VDiagram hierarchy illustrating the relationshipof a parent VDiagram, child VDiagram, and srnholder for a simplegraphical program;

FIG. 12 is a flowchart diagram illustrating the process of building aVDiagram tree for a graphical program;

FIG. 13 is a simple graphical program used as an example of building aVDiagram;

FIG. 14 is a more detailed flowchart diagram illustrating the stepadding VDiagram information for each object in a graphical program;

FIG. 15 is a block diagram representing a VDiagram for the exampleprogram of FIG. 13;

FIG. 16 is an example graphical program containing a while loopstructure;

FIGS. 17A and 17B are partial graphical programs illustrating aspects ofthe graphical program of FIG. 16;

FIG. 18 is a flowchart diagram illustrating how the flow of data from aparent VDiagram to a child VDiagram is represented;

FIG. 19 is a block diagram illustrating the relationship among structurecontrollers, srnholders, and child VDiagrams;

FIG. 20 is a block diagram illustrating how a structure controllerdrives the enable ports for a VDiagram representing a while loopsubframe;

FIG. 21 is an example program hierarchy in which the same globalvariable is read in one subprogram and written in another subprogram;

FIGS. 22 and 23 are block diagrams illustrating the hardware representedby VDiagrams for various subprograms of FIG. 21;

FIGS. 24 and 25 are block diagrams illustrating the ports, components,and connections added to VDiagrams for various subprograms of FIG. 21;

FIG. 26 is a block diagram illustrating the ports, signals, andcomponents that are created to manage a global variable resource withtwo read and two write access points;

FIG. 27 is a flowchart diagram illustrating operation where the methodexports an output terminal into a hardware description;

FIG. 28 is a flowchart diagram illustrating operation where the methodexports an input terminal into a hardware description;

FIG. 29 is a flowchart diagram illustrating how a back end program maygenerate VHDL syntax from a VDiagram tree;

FIGS. 30 and 31 illustrate a simple example of operation of the presentinvention, wherein FIG. 30 illustrates a simple graphical program andFIG. 31 is a conceptual diagram of the hardware description of thegraphical program of FIG. 30;

FIGS. 32-34 illustrate another example of operation of the presentinvention, wherein FIG. 32 illustrates a graphical program, FIG. 33illustrates a tree of data structures created in response to thegraphical program of FIG. 32, and FIG. 34 is a conceptual diagram of thehardware description of the graphical program of FIG. 32; and

FIGS. 35-36 illustrate a graphical program called example1.vi.

FIG. 37 illustrates storing data structure listing graphical programingelements and corresponding cost;

FIG. 38 illustrates receiving user input regarding execution time of thehardware implementation of the graphical program;

FIG. 39 illustrates displaying an indication of usage of hardwareresources during creation of the graphical program.

While the invention is susceptible to various modifications andalternative forms specific embodiments are shown by way of example inthe drawings and will herein be described in detail. It should beunderstood however, that drawings and detailed description thereto arenot intended to limit the invention to the particular form disclosed.But on the contrary the invention is to cover all modifications,equivalents and alternative following within the spirit and scope of thepresent invention as defined by the appended claims.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT Incorporation byReference

The following U.S. Patents and patent applications are herebyincorporated by reference in their entirety as though fully andcompletely set forth herein.

U.S. Pat. No. 4,901,221 titled “Graphical System for Modeling a Processand Associated Method,” issued on Feb. 13, 1990.

U.S. Pat. No. 4,914,568 titled “Graphical System for Modeling a Processand Associated Method,” issued on Apr. 3, 1990.

U.S. Pat. No. 5,481,741 titled “Method and Apparatus for ProvidingAttribute Nodes in a Graphical Data Flow Environment”.

U.S. patent application Ser. No. 08/292,091 filed Aug. 17, 1994, titled“Method and Apparatus for Providing Improved Type Compatibility and DataStructure Organization in a Graphical Data Flow Diagram”.

U.S. Pat. No. 5,475,851 titled “Method and Apparatus for Improved Localand Global Variable Capabilities in a Graphical Data Flow Program”.

U.S. Pat. No. 5,497,500 titled “Method and Apparatus for More EfficientFunction Synchronization in a Data Flow Program”.

U.S. patent application Ser. No. 08/474,307 titled “Method and Apparatusfor Providing Stricter Data Type Capabilities in a Graphical Data FlowEnvironment” filed Jun. 7, 1995.

U.S. Pat. No. 5,481,740 titled “Method and Apparatus for ProvidingAutoprobe Features in a Graphical Data Flow Diagram”.

U.S. patent application Ser. No. 08/870,262 titled “System and Methodfor Detecting Differences in Graphical Programs” filed Jun. 6, 1997,whose inventor is Ray Hsu.

U.S. patent application Ser. No. 08/912,445 titled “Embedded GraphicalProgramming System” filed Aug. 18, 1997, whose inventors are Jeffrey L.Kodosky, Darshan Shah, Samson DeKey, and Steve Rogers.

The above-referenced patents and patent applications disclose variousaspects of the LabVIEW graphical programming and development system.

The LabVIEW and BridgeVIEW graphical programming manuals, including the“G Programming Reference Manual”, available from National InstrumentsCorporation, are also hereby incorporated by reference in theirentirety.

FIG. 1—Block Diagram

FIG. 1 is a block diagram illustrating the conversion of a graphicalprogram into hardware and software descriptions. The graphical program300 comprises graphical code, such as interconnected function nodes oricons. The graphical code in the graphical program may use graphicaldata flow and/or graphical control flow constructs. On the display, thegraphical program is represented as interconnected icons or functionnodes. In the memory of the computer system, the graphical program 300comprises data structures representing functional operations, data flowand/or control flow, and execution order. As the user assembles thegraphical program on the display, e.g., by selecting, arranging, andconnecting various icons or function nodes on the display, the datastructures are automatically created and stored in memory.

The graphical program 300 may be created with various development tools.For example, the graphical program may be created using the followingdevelopment systems: LabVIEW, BridgeVIEW, DASYLab, Visual Designer, HPVEE (Visual Engineering Environment), Snap-Master, GFS DiaDem,ObjectBench, Simulink, WiT, Vision Program Manager, Hypersignal,VisiDAQ, VisSim, Truly Visual, and Khoros, among others. In thepreferred embodiment, graphical program 300 is a LabVIEW graphicalprogram or virtual instrument (VI).

Programs of the present invention create the VDiagram tree 302 from thedata structures of the graphical program 300. The VDiagram tree 302 isan abstract hardware graph which represents at least a portion of thegraphical program 300. The graph is organized in a way that facilitatesthe generation of specific types of descriptions by back end programs ofthe present invention. In one embodiment, the graphical programmingsystem automatically creates and stores a VDiagram tree 302 (abstracthardware graph) in response to a user's creation of a graphical program.In this instance, conversion from graphical program data structures to aVDiagram tree is not necessary.

A hardware description 304 may be generated from the abstract hardwaregraph 302 by a back end program. The hardware description 304 may be invarious hardware description languages such as VHDL, EDIF, and Verilog.In the preferred embodiment, the hardware description 304 comprises oneor more VHDL files. A hardware netlist 306 may be generated from thehardware description using various synthesis tools. As noted above, theterm “netlist” comprises various intermediate hardware-specificdescription formats comprising information regarding the particularhardware elements required to implement a hardware design and therelationship among those elements. In the preferred embodiment, thehardware netlist 306 is an FPGA-specific netlist. The hardware netlist306 is used to create or configure one or more functional hardwaredevices or hardware elements 308 which are configured to execute theportion of the graphical program 300 that is represented by the abstracthardware graph 302.

Hardware element 308 may comprise any of various devices. For example,hardware 308 may comprise a programmable logic device (PLD) such as anFPGA or CPLD. However, hardware 308 may comprise other types of hardwaredevices, such as a traditional circuit board which is created using thehardware netlist 306. In the preferred embodiment, hardware 308 is aninterface card comprising an FPGA, wherein the interface card iscomprised in the computer system where the graphical program 300 iscreated. The hardware 308 may also be comprised in an external deviceconnected to the computer system where the graphical program 300 iscreated. The hardware 308 may be connected to the computer over anexternal serial or parallel bus, or over a network, such as theInternet.

As shown in FIG. 1, software description source code 310 may also begenerated from the abstract hardware graph 302 by a back end program.The source code 310 may be in various source code languages such as C,C++, Java, etc. Machine code 312 may be produced from the source code310 using various source code compilers. Linked machine code 314 may beproduced from the machine code 312 using various machine code linkers.The linked machine code 314 is executable to perform the operations ofthe portion of the graphical program 300 that is represented by theabstract hardware graph 302.

FIG. 2—Block Diagram

FIG. 2 is a block diagram illustrating the generation of various typesof hardware and software descriptions from a VDiagram tree. As describedfor FIG. 1, programs of the present invention create a VDiagram tree 302from a graphical program 300. The VDiagram tree 302 represents at leasta portion of the graphical program 300. Back end programs 330 generatehardware descriptions from the VDiagram tree 302. Exemplary back endprograms 330A, 330B, and 330C are illustrated. Back end 330A generates aVHDL hardware description comprising one or more VHDL files. Back end330B generates an EDIF hardware description comprising one or more EDIFfiles. Back end 330C generates a C source code software descriptioncomprising one or more C files.

The number and type of back end programs that may be present are notlimited. In the preferred embodiment, one or more back end programs maybe called automatically as part of a process initiated by a user togenerate hardware/software descriptions for the graphical program 300.In another embodiment, the VDiagram tree 302 may be generated and savedto a file, and the user may call a back end program at a later time togenerate a hardware/software description.

As described above for FIG. 1, appropriate synthesis tools or compilersmay be called to convert a hardware/software description into anotherformat such as an FPGA-specific netlist or compiled machine code.

FIG. 3—Block Diagram

FIG. 3 illustrates the exportation of at least a portion of a graphicalprogram 300 into a hardware description and the use of the hardwaredescription to program an FPGA. As described above for FIG. 1, theVDiagram tree 302 comprises information representing the graphicalprogram 300, including the functional operations of the program. Asdescribed in detail below, the VDiagram tree comprises VDiagrams, eachof which maintains a list of components. This list of componentsincludes components which represent functional operations.

A back end program converts the VDiagram tree 302 to a hardwaredescription 304. Back end programs may implement the functionality ofthe components in the VDiagram component lists using constructs of theirrespective description languages. For example, a VHDL back end maycreate VHDL code to implement a component that performs a particularmathematical algorithm such as an exponential calculation. However, inthe preferred embodiment, such functional components are simplyreferenced as library components.

FIG. 3 illustrates the preferred embodiment in which the VDiagram treereferences one or more library components. The present inventioncomprises pre-compiled function blocks 342 which implement these librarycomponents for particular hardware devices such as FPGAs. Various FPGAnetlist synthesis tools may be called to generate an FPGA netlist 340from the hardware description 304. These synthesis tools may incorporatethe pre-compiled function blocks 342 into the FPGA netlist 340. Also, asshown, the synthesis tools may utilize hardware target-specificinformation in creating the netlist. For example, the exact form thatthe FPGA netlist takes may depend on the particular type of FPGA thatwill use the netlist, since FPGAs differ in their available resources.

An FPGA bit stream program file 346 may be generated from the FPGAnetlist 340 using readily available synthesis tools. This FPGA programfile may be uploaded to an FPGA 348. The FPGA 348 may be comprised in ahardware device such as an interface board. After being programmed withthe program file 346, the FPGA is able to execute the portion of thegraphical program 300 that is exported to the hardware description 304.If the entire graphical program is not exported to the hardwaredescription, then a portion of the program may execute on the generalpurpose CPU of the computer system. This portion preferably comprisesthe supervisory control and display portion of the program. Detailsfollow on how the execution of the FPGA portion is coordinated with theexecution of the main CPU portion and how the external hardware resourcerequirements for the FPGA portion are managed.

FIG. 4—Block Diagram

FIG. 4 illustrates the exportation of at least a portion of a graphicalprogram 300 into a software source code description and the compilationand linkage of the source code. As shown, the graphical program datastructures may be first converted to a VDiagram tree 302 and then tosoftware description source code 310.

As described above for FIG. 3, in the preferred embodiment the VDiagramtree 302 references library components to represent various functionalcomponents of the graphical program. These library components may beimplemented in libraries, class libraries, macro definitions, etc. 360.As shown in FIG. 4, these class libraries, etc. may be used to producethe machine code 312 from the source code 310. Also, binary objectlibraries 362 may implement some functionality of the softwaredescription. These binary object libraries may be linked in with themachine code 312 is linked to produce the linked executable code 314.Libraries 360 and 362 may also contain compiler-specific orplatform-specific information necessary to produce executable code 314.Linked code 314 may be executed to perform the operations of the portionof the graphical program that is exported to the software source codedescription 310.

FIGS. 5A and 5B—Instrumentation and Industrial Automation Systems

The following describes embodiments of the present invention involvedwith controlling and/or modeling instrumentation or industrialautomation hardware. However, it is noted that the present invention canbe used to create hardware implementations of graphical programs for aplethora of applications and are not limited to instrumentation orindustrial automation applications. In other words, the followingdescription is exemplary only, and the present invention may be used inany of various types of systems. Thus, the system and method of thepresent invention is operable for automatically creating hardwareimplementations of graphical programs or graphical code for any ofvarious types of applications, including the control of other types ofdevices such as multimedia devices, video devices, audio devices,telephony devices, Internet devices, etc., as well as general purposesoftware applications such as word processing, spreadsheets, networkcontrol, games, etc.

FIG. 5A illustrates an instrumentation control system 100. The system100 comprises a host computer 102 which connects to one or moreinstruments. The host computer 102 comprises a CPU, a display screen,memory, and one or more input devices such as a mouse or keyboard asshown. The computer 102 connects through the one or more instruments toanalyze, measure or control a unit under test (UUT) or process 150.

The one or more instruments may include a GPIB instrument 112 andassociated GPIB interface card 122, a data acquisition board 114 andassociated signal conditioning circuitry 124, a VXI instrument 116, aPXI instrument 118, a video device 132 and associated image acquisitioncard 134, a motion control device 136 and associated motion controlinterface card 138, and/or one or more computer based instrument cards142, among other types of devices.

The GPIB instrument 112 is coupled to the computer 102 via the GPIBinterface card 122 provided by the computer 102. In a similar manner,the video device 132 is coupled to the computer 102 via the imageacquisition card 134, and the motion control device 136 is coupled tothe computer 102 through the motion control interface card 138. The dataacquisition board 114 is coupled to the computer 102, and preferablyinterfaces through signal conditioning circuitry 124 to the UUT. Thesignal conditioning circuitry 124 preferably comprises an SCXI (SignalConditioning eXtensions for Instrumentation) chassis comprising one ormore SCXI modules 126.

The GPIB card 122, the image acquisition card 134, the motion controlinterface card 138, and the DAQ card 114 are typically plugged in to anI/O slot in the computer 102, such as a PCI bus slot, a PC Card slot, oran ISA, EISA or MicroChannel bus slot provided by the computer 102.However, these cards 122, 134, 138 and 114 are shown external tocomputer 102 for illustrative purposes. These devices may also beconnected to the computer 102 through a serial bus or through othermeans.

The VXI chassis or instrument 116 is coupled to the computer 102 via aVXI bus, MXI bus, or other serial or parallel bus provided by thecomputer 102. The computer 102 preferably includes VXI interface logic,such as a VXI, MXI or GPIB interface card (not shown), which interfacesto the VXI chassis 116. The PXI chassis or instrument is preferablycoupled to the computer 102 through the computer's PCI bus.

A serial instrument (not shown) may also be coupled to the computer 102through a serial port, such as an RS-232 port, USB (Universal Serialbus) or IEEE 1394 or 1394.2 bus, provided by the computer 102. Intypical instrumentation control systems an instrument will not bepresent of each interface type, and in fact many systems may only haveone or more instruments of a single interface type, such as only GPIBinstruments.

In the embodiment of FIG. 5A, one or more of the devices connected tothe computer 102 include programmable or reconfigurable hardwareaccording to the present invention. For example, one or more of the GPIBcard 122, the DAQ card 114, a VXI card in VXI chassis 116, a PXI card inPXI chassis 118, the image acquisition board 134, the motion controlboard 138, or a computer-based instrument, include programmable hardwareaccording to the present invention. Alternatively, or in addition, oneor more of the GPIB instrument 112, the VXI instrument 116, the serialinstrument, or another type of device include programmable hardwareaccording to the present invention. Where the programmable hardware iscomprised on a VXI or PXI card, the programmable hardware may beconfigured to control one or more other VXI or PXI cards, respectively,comprised in the respective chassis. In the preferred embodiment, theprogrammable hardware comprises a field programmable gate array (FPGA).

The instruments are coupled to the unit under test (UUT) or process 150,or are coupled to receive field signals, typically generated bytransducers. The system 100 may be used in a data acquisition andcontrol application, in a test and measurement application, a processcontrol application, or a man-machine interface application.

FIG. 5B illustrates an exemplary industrial automation system 160. Theindustrial automation system 160 is similar to the instrumentation ortest and measurement system 100 shown in FIG. 5A. Elements which aresimilar or identical to elements in FIG. 5A have the same referencenumerals for convenience. The system 160 comprises a computer 102 whichconnects to one or more devices or instruments. The computer 102comprises a CPU, a display screen, memory, and one or more input devicessuch as a mouse or keyboard as shown. The computer 102 connects throughthe one or more devices to a process or device 150 to perform anautomation function, such as MMI (Man Machine Interface), SCADA(Supervisory Control and Data Acquisition), portable or distributed dataacquisition, process control, advanced analysis, or other control.

The one or more devices may include a data acquisition board 114 andassociated signal conditioning circuitry 124, a PXI instrument 118, avideo device 132 and associated image acquisition card 134, a motioncontrol device 136 and associated motion control interface card 138, afieldbus device 170 and associated fieldbus interface card 172, a PLC(Programmable Logic Controller) 176, a serial instrument 182 andassociated serial interface card 184, or a distributed data acquisitionsystem, such as the Fieldpoint system available from NationalInstruments, among other types of devices.

The DAQ card 114, the PXI chassis 118, the video device 132, and theimage acquisition card 136 are preferably connected to the computer 102as described above. The serial instrument 182 is coupled to the computer102 through a serial interface card 184, or through a serial port, suchas an RS-232 port, provided by the computer 102. The PLC 176 couples tothe computer 102 through a serial port, Ethernet port, or a proprietaryinterface. The fieldbus interface card 172 is preferably comprised inthe computer 102 and interfaces through a fieldbus network to one ormore fieldbus devices. Each of the DAQ card 114, the serial card 184,the fieldbus card 172, the image acquisition card 134, and the motioncontrol card 138 are typically plugged in to an I/O slot in the computer102 as described above. However, these cards 114, 184, 172, 134, and 138are shown external to computer 102 for illustrative purposes. In typicalindustrial automation systems a device will not be present of eachinterface type, and in fact many systems may only have one or moredevices of a single interface type, such as only PLCs. The devices arecoupled to the device or process 150.

In the embodiment of FIG. 5B, one or more of the devices connected tothe computer 102 include programmable hardware according to the presentinvention. For example, one or more of the data acquisition board 114,the serial instrument 142, the serial interface card 152, the PLC 144,or the fieldbus network card 156 include programmable hardware accordingto the present invention. In the preferred embodiment, the programmablehardware comprises a field programmable gate array (FPGA).

As noted above, the programmable hardware may be comprised in a devicewhich connects to the computer 102 over a network, such as the Internet.In one embodiment, the user operates to select a target device from aplurality of possible target devices for programming or configurationaccording to the present invention.

Referring again to FIGS. 5A and 5B, the computer 102 preferably includesa memory medium on which computer programs according to the presentinvention are stored. As used herein, the term “memory medium” includesa non-volatile medium, e.g., a magnetic media or hard disk, or opticalstorage; a volatile medium, such as computer system memory, e.g., randomaccess memory (RAM) such as DRAM, SRAM, EDO RAM, RAMBUS RAM, DR DRAM,etc.; or an installation medium, such as a CD-ROM or floppy disks 104,on which the computer programs according to the present invention arestored for loading into the computer system. The term “memory medium”may also include other types of memory.

The memory medium may be comprised in the computer 102 where theprograms are executed or may be located on a second computer which iscoupled to the computer 102 through a network, such as a local areanetwork (LAN), a wide area network (WAN), or the Internet. In thisinstance, the second computer operates to provide the programinstructions through the network to the computer 102 for execution.

The software programs of the present invention are stored in a memorymedium of the respective computer 102, or in a memory medium of anothercomputer, and executed by the CPU. The CPU executing code and data fromthe memory medium thus comprises a means for converting graphicalprograms into hardware implementations according to the steps describedbelow.

The memory medium preferably stores a graphical programming developmentsystem for developing graphical programs. The memory medium also storescomputer programs according to the present invention which areexecutable to convert at least a portion of a graphical program into aform for configuring or programming the programmable hardware or FPGA.

The instruments or devices in FIGS. 5A and 5B are controlled bygraphical software programs, optionally a portion of which execute onthe CPU of the computer 102, and at least a portion of which areuploaded to the programmable hardware element for hardware execution.The graphical software programs which perform data acquisition, analysisand/or presentation, e.g., for instrumentation control or industrialautomation, may be referred to as virtual instruments.

In the preferred embodiment, the present invention is comprised in theLabVIEW or BridgeVIEW graphical programming systems, hereaftercollectively referred to as LabVIEW, available from NationalInstruments. Also, in the preferred embodiment, the term “LabVIEW” isintended to include graphical programming systems which include Gprogramming functionality, i.e., which include at least a portion ofLabVIEW graphical programming functionality, including the BridgeVIEWgraphical programming system.

Also, the term “graphical programming system” is intended to include anyof various types of systems which are used to develop or creategraphical code or graphical programs, including LabVIEW, BridgeVIEW, andDASYLab from National Instruments, Visual Designer from IntelligentInstrumentation, Hewlett-Packard's VEE (Visual Engineering Environment),Snap-Master by HEM Data Corporation, GFS DiaDem, and ObjectBench by SES(Scientific and Engineering Software), Simulink, WiT, Vision ProgramManager, Hypersignal, VisiDAQ, VisSim, and Khoros, among others.

Although in the preferred embodiment the graphical programs andprogrammable hardware are involved with data acquisition/generation,analysis, and/or display, and for controlling or modelinginstrumentation or industrial automation hardware, as noted above thepresent invention can be used to create hardware implementations ofgraphical programs for a plethora of applications and is not limited toinstrumentation or industrial automation applications. In other words,FIGS. 5A and 5B are exemplary only, and the present invention may beused in any of various types of systems. Thus, the system and method ofthe present invention is operable for automatically creating hardwareimplementations of graphical programs or graphical code for any ofvarious types of applications, including general purpose softwareapplications such as word processing, spreadsheets, network control,games, etc.

FIG. 6—Computer Block Diagram

FIG. 6 is a block diagram of the computer 102 of FIGS. 5A and 5B. Theelements of a computer not necessary to understand the operation of thepresent invention have been omitted for simplicity. The computer 102includes at least one central processing unit or CPU 160 which iscoupled to a processor or host bus 162. The CPU 160 may be any ofvarious types, including an x86 processor, a PowerPC processor, a CPUfrom the Motorola family of processors, a CPU from the SPARC family ofRISC processors, as well as others. Main memory 166 is coupled to thehost bus 162 by means of memory controller 164. The main memory 166stores a graphical programming system, and also stores software forconverting at least a portion of a graphical program into a hardwareimplementation. This software will be discussed in more detail below.The main memory 166 also stores operating system software as well as thesoftware for operation of the computer system, as well known to thoseskilled in the art.

The host bus 162 is coupled to an expansion or input/output bus 170 bymeans of a bus controller 168 or bus bridge logic. The expansion bus 170is preferably the PCI (Peripheral Component Interconnect) expansion bus,although other bus types can be used. The expansion bus 170 includesslots for various devices such as the data acquisition board 114 (ofFIG. 5), a GPIB interface card 122 which provides a GPIB bus interfaceto the GPIB instrument 112 (of FIG. 5), and a VXI or MXI bus card 230coupled to the VXI chassis 116 for receiving VXI instruments. Thecomputer 102 further comprises a video display subsystem 180 and harddrive 182 coupled to the expansion bus 170.

One or more of the interface cards or devices coupled to the expansionbus, such as the DAQ card 114, the GPIB interface card 122, or the GPIBinstrument 112 comprises programmable hardware such as a fieldprogrammable gate array (FPGA). The computer 102 may also include anetwork interface card for coupling to a network, wherein the targetdevice containing the programmable hardware is coupled to the network.

FIG. 7—Programmable Hardware Diagram

FIG. 7 is a block diagram illustrating a device, e.g., an interfacecard, configured with programmable hardware according to the presentinvention. It is noted that FIG. 7 is exemplary only, and an interfacecard or device configured with programmable hardware according to thepresent invention may have various architectures or forms, as desired.For example, the device may be internal or external to the computer 102,and may be connected to the computer through a network, such as theInternet. The interface card illustrated in FIG. 7 is the DAQ interfacecard 114 shown in either of FIG. 5A or 5B. However, as noted above, theprogrammable hardware may be included on any of the various devicesshown in FIG. 5A or 5B, or on other devices, as desired. Also, theprogrammable hardware illustrated in FIG. 7 is an FPGA, but the devicemay include another type of programmable hardware instead, such as aCPLD or other type of (re)configurable hardware.

As shown, the interface card 114 includes an I/O connector 202 which iscoupled for receiving signals. In the embodiments of FIGS. 5A and 5B,the I/O connector 202 presents analog and/or digital connections forreceiving/providing analog or digital signals. The I/O connector 202 isadapted for coupling to SCXI conditioning logic 124 and 126, or isadapted to be coupled directly to a unit under test 130 or process 160.

The interface card 114 also includes data acquisition (DAQ) logic 204.As shown, the data acquisition logic 204 comprises analog to digital(A/D) converters, digital to analog (D/A) converters, timer counters(TC) and signal conditioning (SC) logic as shown. The DAQ logic 204provides the data acquisition functionality of the DAQ card 114. In oneembodiment, the DAQ logic 204 comprises 4 A/D converters, 4 D/Aconverters, 23 digital I/Os, a RTSI connector, and a TIO. This extrahardware is useful for signal processing and motion controlapplications. The programmable hardware element or FPGA can access theseresources directly, thereby enabling creation of very powerful DSP andcontrol applications, among others.

According to the preferred embodiment of the invention, the interfacecard 114 includes a programmable hardware element or programmableprocessor 206. In the preferred embodiment, the programmable hardware206 comprises a field programmable gate array (FPGA) such as thoseavailable from Xilinx, Altera, etc. The programmable hardware element206 is coupled to the DAQ logic 204 and is also coupled to the local businterface 208. Thus a graphical program can be created on the computer102, or on another computer in a networked system, and at least aportion of the graphical program can be converted into a hardwareimplementation form for execution in the FPGA 206. The portion of thegraphical program converted into a hardware implementation form ispreferably a portion which requires fast and/or real-time execution

In the embodiment of FIG. 7, the interface card 114 further includes adedicated on-board microprocessor 212 and memory 214. This enables aportion of the graphical program to be compiled into machine languagefor storage in the memory 214 and execution by the microprocessor 212.This is in addition to a portion of the graphical program beingconverted into a hardware implementation form in the FPGA 206. Thus, inone embodiment, after a graphical program has been created, a portion ofthe graphical program is compiled for execution on the embedded CPU 212and executes locally on the interface card 114 via the CPU 212 andmemory 214, and a second portion of the graphical program is translatedor converted into a hardware executable format and uploaded to the FPGA206 for hardware implementation.

As shown, the interface card 114 further includes bus interface logic216 and a control/data bus 218. In the preferred embodiment, theinterface card 114 is a PCI bus-compliant interface card adapted forcoupling to the PCI bus of the host computer 102, or adapted forcoupling to a PXI (PCI eXtensions for Instrumentation) bus. The businterface logic 216 and the control/data bus 218 thus present a PCI orPXI interface.

The interface card 114 also includes local bus interface logic 208. Inthe preferred embodiment, the local bus interface logic 208 presents aRTSI (Real Time System Integration) bus for routing timing and triggersignals between the interface card 114 and one or more other devices orcards.

In one embodiment, the interface card 114 also includes a non-volatilememory (not shown) coupled to the programmable hardware element 206. Thenon-volatile memory is operable to store the hardware descriptionreceived from the host computer system to enable execution of thehardware description in the programmable hardware element 206 prior toor during booting of the computer system 102.

In the embodiment of FIG. 7A, the CPU 212 and memory 214 are notincluded on the interface card 114, and thus only the portion of thegraphical program which is converted into hardware implementation formis uploaded to the FPGA 206. Thus in the embodiment of FIG. 7A, anysupervisory control portion of the graphical program which is necessaryor desired to execute in machine language on a programmable CPU may beexecuted by the host CPU in the computer system 102, and is not executedlocally by a CPU on the interface card 114.

In the embodiment of FIG. 7B, the CPU 212 is not included on theinterface card 114, i.e., the interface card 114 includes the FPGA 206and the memory 214. In this embodiment, the memory 214 is used forstoring FPGA state information. FIG. 7B is the currently preferredembodiment of the present invention.

FIG. 8—Conversion of a Graphical Program into a Hardware Implementations

FIG. 8 is a flowchart diagram illustrating operation of the preferredembodiment of the present invention. The present invention comprises acomputer-implemented method for generating hardware and/or softwareimplementations of graphical programs or graphical code. It is notedthat various of the steps in the flowchart can occur concurrently or indifferent orders.

One goal of the present invention is to provide a developmentenvironment that will seamlessly allow use of a graphical programmingsystem to design applications for reconfigurable or programmablehardware. In the preferred embodiment where the graphical programmingsystem is LabVIEW, the present invention allows LabVIEW users to designapplications in LabVIEW for reconfigurable hardware.

Many applications, such as signal processing and real-time motioncontrol, are easily implemented in a graphical programming language,such as the LabVIEW G language. However, in some instances traditionalsoftware compilation methods cannot produce an application that is fastenough to meet a user's needs. The present invention solves this problemby allowing a user to convert their graphical program, e.g., a Gprogram, into application-specific hardware such as a programmed FPGA.The hardware maintains the exact functionality of the graphical programwhile running at speeds far exceeding that of traditionalgeneral-purpose processor platforms. The current implementation of thepresent invention is a desktop or embedded PC that contains anFPGA-based daughter card.

In one embodiment, the present invention appears as a conventionalgraphical programming system while providing a seamless interface to thereconfigurable hardware. For example, the preferred embodiment of theinvention, referred to as “FPGA LabVIEW”, provides a seamless interfaceto an FPGA. FPGA LabVIEW appears from the outside to be exactly the sameas the normal LabVIEW graphical program development system.

FIG. 8 illustrates the translation process from a graphical program to ahardware description that corresponds to the graphical program. Agraphical programming application that is being targeted for a hardwareimplementation is designed in exactly the same way as an ordinarygraphical programming application. As shown, in step 402 the user firstcreates a graphical program, also sometimes referred to as a blockdiagram. A design is entered and debugged in the traditionalsoftware-based manner. In the preferred embodiment, the graphicalprogram comprises a graphical data flow diagram which specifiesfunctionality of the program to be performed. This graphical data flowdiagram is preferably directly compilable into machine language code forexecution on a computer system.

When the design is finalized, the user can instruct the system tocompile the design for the FPGA hardware. Unfortunately, some graphicalprogramming constructs may not be efficiently implemented in FPGAhardware. For example, file I/O is a task that is usually better left tothe general-purpose host processor. The present invention is capable ofbisecting a design into hardware portions and software portions.

In step 404, the user selects a first portion of the graphical programfor conversion to a hardware implementation. This first portion of thegraphical program which is desired for hardware implementationpreferably comprises portions of the graphical program, e.g., particularsubprograms, which require a fast or deterministic implementation and/orare desired to execute in a stand-alone hardware unit. In general,portions of the graphical program which are desired to have a faster ormore deterministic execution are selected in step 404 and converted intothe hardware implementation in steps 406-414.

In step 422 the remaining portions of the graphical program which werenot selected in step 404 are compiled into machine code for execution ona CPU, such as the host CPU in the computer 102 or the CPU 212 comprisedon the interface card 114. The first portion of the program selected instep 404 preferably excludes program portions involving supervisorycontrol and display. This enables the supervisory control and displayportions to execute on the host CPU, which is optimal for these elementsof the program.

In one embodiment, during creation of the graphical program in step 402the user specifies portions, e.g. subprograms, which are to exported tothe hardware description format for conversion into a hardwareimplementation. In another embodiment the user selects which modules orsubprograms to export to the hardware implementation at the time whenthe conversion process is initiated. In another embodiment, the entiregraphical program is selected for conversion to a hardwareimplementation, and thus step 422 is not performed.

In step 406 the graphical program portion selected in step 404 is firstprocessed to create an abstract hardware graph called a VDiagram treewhich serves as an intermediate data structure. The VDiagram treecontains a complete hardware representation of the program, but is notspecific to any hardware description language. For example, the VDiagramtree comprises data structures representing hardware signals thatimplement the data flow within the graphical program, as well as datastructures representing hardware signals that are added to preserve theproper execution flow (enable signals).

In step 408, a back end program is called to parse the VDiagram tree andgenerate a hardware description from it. The back end translates theinformation contained in the VDiagram tree into a specific hardwaredescription language. For example, a VHDL back end may be called togenerate a VHDL file or set of files describing the program. Thehardware description comprises a high-level hardware description offunction blocks, logic, inputs, and outputs which perform the operationindicated by the portion of the graphical program selected in step 404.

Various types of back end programs may be present. Back end programs maygenerate software source code descriptions as well as hardwaredescription language descriptions. For example, FIG. 2 illustrates aback end 330A which uses the VDiagram tree to generate one or more VHDLfiles; back end 330B which generates one or more EDIF files; and backend 330C which generates one or more C files. These three back ends arerepresentative only. Other back ends may generate other types ofdescriptions for the program. For example, a Verilog back end maygenerate a Verilog file for the program. Also, more than one back endmay be called to generate different program descriptions. In thepreferred embodiment, a VHDL back end generates a VHDL description whichmay then be compiled and used to program a programmable logic devicesuch as an FPGA.

In step 410 the method operates to convert the hardware description intoan FPGA-specific netlist. The netlist describes the components requiredto be present in the hardware as well as their interconnections.Conversion of the hardware description into the FPGA-specific netlist ispreferably performed by any of various types of commercially availablesynthesis tools, such as those available from Xilinx, Altera, etc.

In the preferred embodiment, the converting step 410 may utilize one ormore pre-compiled function blocks from a library of pre-compiledfunction blocks 342. Thus, for certain function blocks which aredifficult to compile, or less efficient to compile, from a hardwaredescription into a netlist format, the hardware description created instep 408 includes a reference to a pre-compiled function block from thelibrary 342. Alternatively, hardware implementations for all of thefunction blocks are included in the function library. The respectivepre-compiled function blocks are simply inserted into the netlist inplace of these references in step 410. The preferred embodiment of theinvention thus includes the library 342 of pre-compiled function blocks,also referred to as the component library, which are used in creatingthe netlist. The preferred embodiment also includes hardware targetspecific information 344 which is used by step 410 in converting thehardware description into a netlist which is specific to a certain typeor class of FPGA.

In step 412 the method operates to compile the netlist into an FPGAprogram file, also referred to as a software bit stream. The FPGAprogram file is a file that can be readily uploaded to program an FPGA.

After the netlist has been compiled into an FPGA program file in step412, then in step 414 the method operates to transfer the FPGA programfile to the FPGA, to produce a programmed hardware equivalent to thegraphical program. Thus, upon completion of step 414, the portion of agraphical program referenced in step 404 is comprised as a hardwareimplementation in an FPGA or other programmable hardware element.

In the preferred embodiment, the hardware description is passedtransparently through the FPGA vendor's synthesis tools. Because thevendor's tools may take a considerable amount of time to process thedesign and generate a programming bitstream, it is recommended that thisonly be done after the design has been debugged using traditionalsoftware-compilation techniques.

As described above, the present invention may run on PC computersequipped with an FPGA-based expansion card on the PCI bus. Embodimentsof the FPGA-based expansion card were described with reference to FIGS.7, 7A and 7B. The graphical programming system uploads the programmingbitstream generated by the FPGA vendor's design tools into the FPGA onthis board. The FPGA then begins processing data, and the graphicalprogramming system may coordinate data flow between the FPGA and thehost CPU.

It is noted that various of the above steps can be combined and/or canbe made to appear invisible to the user. For example, steps 410 and 412can be combined into a single step, as can steps 404-410. In thepreferred embodiment, after the user creates the graphical program instep 402, the user simply selects a hardware export option and indicatesthe hardware target or destination, causing steps 404-414 to beautomatically performed.

FIG. 8 applies to the preferred embodiment in which the programmablehardware element is an FPGA. However, the same or similar steps may beapplied to convert a graphical program into a hardware implementationfor other types of programmable or (re)configurable hardware, such as aCPLD.

FIG. 9—Creation of a Graphical Program

FIG. 9 is a more detailed flowchart diagram of step 402 of FIG. 8,illustrating creation of a graphical program according to the preferredembodiment of the invention. As shown, in step 420 the user arranges onthe screen a graphical program or block diagram. This includes the userplacing and connecting, e.g., wiring, various icons or nodes on thedisplay screen in order to configure a graphical program. Morespecifically, the user selects various function icons or other icons andplaces or drops the icons in a block diagram panel, and then connects or“wires up” the icons to assemble the graphical program. The user alsopreferably assembles a user interface, referred to as a front panel,comprising controls and indicators which indicate or representinput/output to/from the graphical program. The graphical program issometimes referred to as a virtual instrument (VI). The graphicalprogram or VI will typically have a hierarchy of sub-graphical programsor sub-VIs.

In the preferred embodiment, the graphical programming system is theLabVIEW graphical programming system available from NationalInstruments. For more information on creating a graphical program in theLabVIEW graphical programming system, please refer to the LabVIEW systemavailable from National Instruments as well as the above patentapplications incorporated by reference.

In response to the user arranging on the screen a graphical program, themethod operates to develop and store a tree of data structures whichrepresent the graphical program. Thus, as the user places and arrangeson the screen function nodes, structure nodes, input/output terminals,and connections or wires, etc., the graphical programming systemoperates to develop and store a tree of data structures which representthe graphical program. More specifically, as the user assembles eachindividual node and wire, the graphical programming system operates todevelop and store a corresponding data structure in the tree of datastructures which represents the individual portion of the graphicalprogram that was assembled. Thus, steps 420 and 421 are an iterativeprocess which is repetitively performed as the user creates thegraphical program. In one embodiment, the graphical programming systemautomatically develops and stores VDiagram data structures in responseto the user creating the graphical program.

In one embodiment, the user optionally places constructs in thegraphical program which indicate respective portions of graphical codewhich are either to be compiled into machine code for execution by a CPUor converted to a hardware description for implementation in aprogrammable hardware device such as an FPGA.

FIGS. 10 and 11—VDiagram Tree Structures

The VDiagram tree comprises data structures called VDiagrams. The rootVDiagram contains information for the program items present in thetop-level graphical program, such as wires, constants, etc. Any complexitems such as sub-programs, functions, loop structures, etc. arerepresented as child VDiagrams. Parent VDiagrams have pointers to alltheir child VDiagrams so that a tree is formed for the programhierarchy. Each child VDiagram also has a pointer back to its parent.

The VDiagram code is preferably written in C++. The following pseudocodedescribes the contents of each VDiagram:

class VDiagram { public: VComponentList complist; VSignalListsignallist; VAssignmentList assignlist; VSubvlList arnlist; VSubviListsubvilist; VPortMap topporttrap; VResourceList resourcelist; private:int isSubvi; VDiagram *owner; VComponent *srnholate; ObjID rootobj; char*entityname; };

FIG. 10 provides a graphical representation of a VDiagram and therelationship among its elements. Each of these elements is discussedbelow. Note that specific graphical program components and constructsare discussed below, such as wires, functions, sequence structures, casestructures, loops, loop tunnels, shift registers, etc. For moreinformation on these concepts, please see the above-referenced patentsor the LabVIEW documentation available from National Instruments.

complist

The component list contains a list of components that appear in thegraphical program. The VDiagram thus preserves some of the structurepresent in a graphical program so that it appears in the resultinghardware description. Components include functions such as adders,multipliers, and comparators. Components also include objects thatrepresent higher-level programming constructs such as while loops andsequences. Components also include sub-programs. Components on the listare subdivided by type. In the preferred embodiment in which a VHDLdescription is generated from the VDiagram tree, components generallycorrespond exactly to entities in a VHDL file.

signallist

The signal list stores all of the wires for the VDiagram. This includesall of the wires that appear on the graphical program itself, as well asany hardware-specific wires that are added, such as the clock and resetsignals. Each signal stores a list of the components that it attachesto.

assignlist

Signals can be divided into two groups: signals that are driven bycomponents and signals that are driven by other signals. The assignmentlist contains objects that describe relations of the latter type.Examples include boolean expressions, multiplexers, and decoders. Forexample, if a component has multiple input signals, it will need to havean enable signal that is composed of an AND of the enable out signalscorresponding to the inputs. The assignment list will contain an entryspecifying this relationship.

srnlist

This list contains pointers to additional VDiagrams, each of whichrepresents a subframe of a graphical program. A subframe is the areainside of a structural component such as a while loop, a sequence frame,a case structure, etc. The root object of a subframe is a self referencenode (SRN) which encloses the entire subframe. See the descriptionsbelow and the above-referenced documentation for more information.

subvilist

Similar to the srnlist, the subvilist contains pointers to additionalVDiagrams. These VDiagrams represent subvi's (subprograms) instead ofsubframes. The distinction between subvi and subframe is made to helpthe VDiagram back ends keep the hardware description organized. Forexample, the VHDL back end may keep all of the subframes of a programtogether in the same file, but may place the VHDL generated forsubprograms in separate files.

The root object of a subprogram is a self reference node (SRN) whichencloses the entire subprogram. See the descriptions below for moreinformation.

topportmap

The topportmap is a list of ports that describe the connections betweena graphical subprogram or subframe and its parent. These connectionsinclude things like data tunnels (a connection between a program and aloop's subframe), global variable hardware register connections, andother hardware-specific signals such as clock and reset.

resourcelist

The resourcelist is a list that keeps track of where hardware resourceslike A/D converters, D/A converters, and global variables are being usedin the VDiagram tree. Parent VDiagrams inherit resource information fromtheir children. (The VDiagram tree is built in a depth-first manner.) Atthe top-level VDiagram, the consolidated resource information from allchild VDiagrams is used to build the logic that connects externalhardware resources to the components that use them.

isSubvi

This is an integer used to identify the type of the VDiagram. There arethree possibilities: V_TOPLEVELVI, V_SUBVI, and V_SRNVI. The top-levelVDiagram is flagged as V_TOPLEVELVI. Child VDiagrams are flagged asV_SUBVI if they correspond to a subprogram, or V_SRNVI if theycorrespond to a subframe. See the descriptions for subvilist andsrnvilist for more information.

owner, srnholder

The owner pointer points back to the parent VDiagram. The srnholderpointer points back to the srnholder in the parent VDiagram's componentlist. FIG. 11 shows an example VDiagram hierarchy illustrating therelationship of a parent VDiagram, child VDiagram, and smholder for avery simple graphical program containing a single subprogram. In thisexample, an srnholder appears in the parent VDiagram's component list.This srnholder points to the child VDiagram representing the subprogram.The parent VDiagram also contains an entry in its subvilist that pointsto the child VDiagram. As shown in FIG. 11, a child VDiagram points toboth its parent VDiagram and its parent smholder.

rootobj

The rootobj pointer points to the root object that the VDiagramrepresents in the graphical program. In the preferred embodiment, thegraphical program being converted to a hardware description is a LabVIEWVI. In this case the rootobj pointer would point to the root LabVIEWobject for the VDiagram. The root object for a VDiagram may also becalled a self reference node (SRN).

entityname

The entityname character string is a unique name for the VDiagram. Theremay be different naming conventions. For example, the top-level VDiagrammay be named “toplevel,” and the child VDiagrams may be named byconcatenating the hex value of the rootobj pointer with some otherinformation about the graphical program, such as the project name orfile name.

FIG. 12—Building a VDiagram Tree

FIG. 12 is a flowchart diagram illustrating the basic process ofbuilding a VDiagram tree for a graphical program. FIG. 12 shows step 406of FIG. 8 in more detail. In step 450 the VDiagram tree constructorfunction is called for the appropriate root object of the graphicalprogram, i.e. the point in the graphical program where conversion into ahardware description should begin. If the entire graphical program is tobe converted, the constructor function should be called for thetop-level program root object. In the preferred embodiment this is aself reference node (SRN) for the top-level LabVIEW VI. It may bedesirable to translate only a part of the graphical program intohardware. For example, to convert a subprogram into hardware, the rootobject pointer for the subprogram is passed to the VDiagram constructorfunction.

The VDiagram constructor function is also called for each element in theportion of the graphical program to be translated that should berepresented by a separate VDiagram (e.g., subprograms and subframes forloops, sequences, etc.). The constructor function also takes pointerparameters for the VDiagram's owner and smholder (described above) sothat a VDiagram tree is built as shown in FIG. 13. The VDiagram tree isbuilt in a depth-first manner. One reason for this is that a VDiagramneeds to consolidate resource information for itself and all of itschild VDiagrams, so the child VDiagram resource information must bedetermined first.

In step 452 the VDiagram constructor function calls a message handlerfunction to add information and data structures to the VDiagram for eachobject in the portion of the program referenced by the root objectpointer passed to it. For example, VComponents, VSignals, VSigterms,etc. are added to the VDiagram to represent each element of thegraphical program. The message handler that is called is specific to thetype of object, e.g. constant, function, signal, programmatic structure,subprogram, etc. Each message handler function adds any additionalhardware information to the VDiagram that is necessary to convert theobject into a hardware design but is not represented in the originalgraphical program. For example, enable and reset signals are added foreach component. Step 452 is discussed in more detail below in thedescription for FIG. 14.

In step 454 the VDiagram constructor function adds routing informationto the VDiagram for utilizing hardware resources such as A/D converters,global variable hardware registers, etc. Hardware resources requireaccess to specific resources on the programmable logic device (PLD). Forexample, a hardware resource may require a connection to a specific pinon an FPGA. This PLD-specific information is available from thetop-level VDiagram, but not from child VDiagrams. Thus, for childVDiagrams ports are added to the VDiagram's topportmap to routehardware-specific data through its parent VDiagram. At the top-levelVDiagram, all hardware resource information is consolidated and logic isgenerated to interface with resources outside the PLD. More informationon resources and arbitration follows in a later section.

In step 456 the VDiagram constructor function adds reverse pointers fromeach component to the signals connected to its ports. This is doneprimarily to aid in traversal of the VDiagram and is helpful to hardwaredescription back ends.

In step 458 the resourcelist information for the VDiagram isconsolidated with the parent VDiagram's resourcelist. Thus each VDiagramcontains all the resource information necessary to implement itself andits children in hardware, and the top-level VDiagram is able to buildthe proper external interface logic.

FIGS. 13-15: Graphical Program Example

FIG. 13 is a simple graphical program that is used here for an exampleof building a VDiagram. This program contains only three objects: aconstant zero, a signal, and an incrementer function. The signalconnects the output of the constant object to the input of theincrementer function. The incrementer function increments the integervalue of the input by 1. In a real program there would be another signalconnecting the output from the incrementer function to some other inputport, but for simplicity it is not shown here. Depending on theparticular embodiment, some other visible or invisible “object” isassociated with the three objects shown in the diagram to group themtogether. In the case of a LabVIEW VI, this invisible object is called aself reference node (SRN). This grouping object is the same as the rootobject for the graphical program as described above.

The VDiagram is generated by calling the VDiagram constructor functionwith a pointer to the root object, null pointers for the owner andsrnholder parameters, and a flag to indicate that it is a top-levelVDiagram. As shown in FIG. 12, the constructor first performs step 452of calling a message handler function to add information and datastructures to the VDiagram for each object in the graphical program.

FIG. 14 illustrates the steps performed by the method step 452 of FIG.12 in more detail. Each type of object in a graphical program has acorresponding message handler function, and each message handler addsinformation and/or data structures to the VDiagram for representing theobject in hardware. The message handler functions are called in aparticular order. In step 470 any objects in the program that should berepresented as child VDiagrams are processed. The VDiagram constructorfunction is called for objects such as subprograms and subframes (e.g.,the inside of a while loop). Thus, VDiagram information is added in adepth-first manner. There are no objects on the example program of FIG.13 which are represented as separate child VDiagrams.

In step 472, message handlers are called for each of the simple objectspresent in the program such as constants, indicators for front paneldisplays, sequence local variables, etc. In the example program of FIG.13, the only object present of this type is the constant zero. Themessage handler function for a numeric constant adds information to theVDiagram necessary to instantiate the constant in hardware. A constantis represented in hardware as a signal with an unchanging value. Thusthe message handler adds a new VSignal to the VDiagram's signallist.Flags are set in the VSignal data structure to signify that it is aconstant signal with an initialization value of zero. At this point theVSignal representing the constant zero is not connected to anythingelse. For now it is simply created and stored in the signallist.

After the message handlers for all the simple objects are called in step472, message handlers are called in step 474 to add information and datastructures representing the rest of the nodes in the graphical programto the VDiagram, such as functions. As described above, a graphicalprogram is typically built by connecting “nodes” with “wires”. Each nodeobject represents an operation such as function or subprogram, or aprogrammatic structure such as a loop, or a data source/target such as aconstant or a global variable, etc. Each wire object represents aconnection between node objects. Wires are also called signals.

In the example program of FIG. 13 there are two node objects connectedby a wire. The information for the simple constant node object is addedin step 472. The only other node in the program is the incrementerfunction. The incrementer function message handler is called in step474. The message handler function for the incrementer function adds aVComponent to the VDiagram's complist. In the preferred embodiment, theVComponent contains information referencing a hardware library componentthat may be used to implement the functionality of the incrementerfunction in hardware. This reference to the library component may laterbe used by the back end that generates a particular hardware descriptionfrom the VDiagram. For example, a VHDL back end may generate standardVHDL syntax for an entity declaration and component instantiation. Theentries in the VDiagram's complist are sorted by type so that it is easyto declare components by type and instantiate them individually. Inanother embodiment, the back end may be configured to generate ahardware description that implements the functionality of theincrementer function using constructs of the back end's hardwaredescription language (e.g., VHDL, EDIF, etc.) rather than referencing alibrary component.

After message handlers for all the other objects have been called, amessage handler function is called for each wire (signal) in thegraphical program. This order of generating node information beforesignal information is important. Since signals connect other objects,the information for the objects, such as their port numbers, must beavailable to the signal message handler.

Only one signal is present in the example graphical program: the wirethat connects the constant to the incrementer function. Signals in thegraphical program map directly to VSignals in a VDiagram. The messagehandler creates a new VSignal data structure and adds it to thesignallist. As noted in the description above for the assignlist of aVDiagram, signals can be divided into two groups: signals that aredriven by components and signals that are driven by other signals. TheVSignal representing the wire in the example graphical program is drivenby another signal, since the constant zero is implemented as a hardwaresignal. A VAssignment data structure is added to the VDiagram'sassignlist to represent this relationship. A pointer is added from theVSignal representing the wire in the program to the VAssignmentspecifying the signal-driving relationship. Another pointer is addedfrom the VAssignment to the VSignal representing the constant zero todenote the source of the driving signal in the VAssignment.

The VSignal representing the wire in the example program drives acomponent rather than another signal. This relationship is representedby adding a VSigterm to the VSignal. The VSigterm points to the inputport of the incrementer function component. Additional VSigterms couldbe added for signals that drive more than one component.

Step 452 of FIG. 12 is complete after the message handler function hasbeen called for each signal (step 476 of FIG. 14). As shown, step 454may then add information to the VDiagram for implementinghardware-specific resources. This example will skip step 454. Resourcesand arbitration are discussed in detail below.

In step 456 of FIG. 12, reverse pointers are added from each VComponentto the VSignals connected to its ports. Each VSignal is checked to makesure that its VSigterms point to a valid port on a valid VComponent. Ifthe VSigterm is valid, a return pointer is created from the VComponentport back to the VSignal. In the FIG. 13 example program, the VDiagramcontains only one VSigterm, so only one return pointer is created inthis step. This is a pointer from the input port of the incrementerfunction VComponent to the VSignal representing the wire on thegraphical program.

In step 458 of FIG. 12, the resourcelist information for the VDiagram isconsolidated with the parent VDiagram's resourcelist. However, for thisFIG. 13 example the VDiagram has no parent. The VDiagram tree containsonly the top-level VDiagram. Thus, for the purposes of this example theVDiagram is complete after step 456.

FIG. 15 is a block diagram representing the VDiagram constructed for theexample program of FIG. 13. As noted, this example omitted detailsregarding hardware resources. It also omitted a discussion of signalsthat are added to implement an enable chain among the objects. Theseaspects are discussed below. FIG. 15 illustrates the VDiagram datastructures discussed above and the relationships among them. The hexnumbers shown are example memory addresses for the structures.

FIGS. 16-18: Data Flow Between VDiagrams

Data often flows across component boundaries in a graphical program. Forexample, wires in the main graphical program may go into a subprogram orvice versa, data may cross a loop boundary via a data tunnel, etc. Thisdata flow is preserved in the data flow among VDiagrams in a VDiagramtree. FIGS. 16-18 illustrate data flow between VDiagrams.

FIG. 16 is a graphical program containing a while loop structure. Asshown, a signal passes from the constant zero through a data tunnel intothe while loop. As discussed above, programmatic structures such aswhile loops are represented as child VDiagrams of the parent VDiagram.FIG. 17A illustrates the graphical program from the point of view of theparent VDiagram. The parent VDiagram contains information representingthe constant zero and the container object for the while loop. It viewsthe while loop as a black box through which data enters via a datatunnel. FIG. 17B illustrates the graphical program from the point ofview of the child VDiagram. The child VDiagram contains informationrepresenting the while loop subframe. Data enters the subframe via adata tunnel and flows to the incrementer function.

FIG. 18 is a flowchart diagram illustrating how the flow of data from aparent VDiagram to a child VDiagram is represented. As noted above, aVDiagram tree is constructed in a depth-first manner. The flowchart thusbegins with what occurs for the child VDiagram. In step 480 a new VPortdata structure is created and added to the child VDiagram's topportmap.In step 482 a new VSignal is created and added to the child VDiagram'ssignallist. This VSignal represents the wire that appears in the portionof the graphical program represented by the child VDiagram. For example,it may represent the wire of FIG. 17B that connects to the incrementerfunction. The VSignal is mapped to the VPort created in step 480 tosignify that the signal enters the child VDiagram from an externalsource.

In step 484 the VSignal created in step 482 is connected to itsdestination. For example, in FIG. 17B the wire shown connects to theinput port of the incrementer function. In this example, a VSigtermpointing to the input port of the VComponent representing theincrementer function is added to the VSignal. If the VSignal drivesanother signal instead of a component, a VAssignment is created in step484 instead of a VSigterm.

In step 486 the VPort created in step 480 is added to the port map ofthe child VDiagram's srnholder. In step 488 the VPort is added to thecomplist of the parent VDiagram. The VPort created for the childVDiagram in step 480 is thus available to the parent VDiagram to use tosend data into the child VDiagram.

In step 490 a new VSignal is created and added to the parent VDiagram'ssignallist. This VSignal data structure represents the wire on thegraphical program that enters into the portion of the programrepresented by the child VDiagram. For example, it may represent thewire of FIG. 17A that originates from the output port of the constantzero object and enters the while loop subframe. A signal that crossesbetween VDiagram boundaries is thus represented as two separate VSignaldata structures: one in the child VDiagram (created in step 482) and onein the parent VDiagram (created in step 490).

In step 492 the two VSignals created in steps 482 and 490 are connected.A VSigterm is added to the parent VDiagram's VSignal which points to theVPort that was added to the parent VDiagram's complist in step 488. Thusthe two VSignals are now joined via the VPort.

In step 494 the parent VDiagram's VSignal is mapped to its drivingsource. For the example program of FIG. 17, this mapping is accomplishedby creating a VAssignment specifying that the VSignal is driven byanother VSignal which represents the constant zero.

The example above is for data flowing from a parent VDiagram into achild VDiagram. The VDiagram tree may represent data flowing from achild VDiagram to a parent VDiagram using a similar mechanism. Also, theexample is for data crossing the boundary of a while loop. Data crossingother programmatic construct boundaries and subprogram boundaries mayalso be represented similarly in the VDiagram tree. For example insteadof loop tunnels, a subprogram may have subprogram connectors connectingthe subprogram to front panel controls and indicators. These front paneldata control objects may be associated with ports on the subprogramconnectors using VPorts as described above.

FIG. 19—Case Structure Controller

As described previously, the subframes of complex programmaticstructures such as while loops, for loops, and case structures arerepresented as child VDiagrams. An srnholder, which is a type ofVComponent, is inserted into the parent VDiagram's complist. Thesrnholder VComponent points to the child VDiagram. The parent VDiagramalso points to the child VDiagram. The child VDiagram also points backboth to its srnholder and to its parent VDiagram. This relationship isillustrated in FIG. 11. (One difference is that FIG. 11 indicates thatthe child VDiagram is a member of the parent VDiagram's subvilist.VDiagrams representing subprograms are members of the parent'ssubvilist. However, VDiagrams representing programmatic structuresubframes are members of the parent VDiagram's srnlist instead.)

A parent VDiagram needs additional information besides an srnholderVComponent and a child VDiagram in order to convert programmaticstructures into hardware. For example, a while loop also needs aniteration counter and a variable representing the continue condition; afor loop needs to run for a specified number of iterations; a casestructure needs to decode its select input, etc. Additional informationis added to a parent VDiagram to fulfill these requirements using astructure controller data structure. A structure controller isrepresented in the VDiagram as another VComponent in the parentVDiagram's complist.

The structure controller VComponent contains ports which connect toiteration count nodes, continue nodes, case select nodes, maximumiteration nodes, etc. The message handler functions which generate theVDiagram information for each type of programmatic structure generatethe appropriate VPorts and VSignals to route the necessary input/outputsignals from these structure controller ports to the child VDiagrams.

FIG. 19 illustrates the relationship among structure controllers,srnholders, and child VDiagrams. The figure illustrates an example for acase structure with two cases (i.e., there are two possible subframes).As shown there is an srnholder for each child VDiagram representing asubframe. Each srnholder points to its corresponding child VDiagram, andeach child VDiagram points back to its srnholder. The smholders alsohave an associated srnholder pointer. These srnholder pointers are usedfor programmatic structures with multiple elements such as casestructures and sequence structures. For these types of structures, thesmholder pointers of the srnholders are used to link together thesrnholders, as shown in FIG. 19. The structure controller points to thesrnholder corresponding to the programmatic structure. For structureswith more than one srnholder, the structure controller points to thefirst srnholder in the list, as shown in the figure.

FIG. 20—Enable Chain Block Diagram

An order of execution is inherent in graphical programs. For example,the order in which two input signal parameters reach a two-integer adderfunction is not important, but it is important that both inputparameters have reached the adder and are valid before the adderfunction performs the addition operation and the program continuesexecution using the output from the adder. Graphical program systems usemechanisms to ensure proper execution order. In order to faithfullyduplicate a software program, hardware designs must also include suchmechanisms. As a VDiagram tree is constructed, an enable chain ismaintained for all components which ensures proper execution order andresolves hardware timing issues.

Three special VPorts are added to every VComponent in a VDiagram'scomplist. These ports are named enable_in, enable_out, and enable_clr.As noted above, objects in a graphical program such as programmaticstructures and functions are implemented in the preferred embodimentusing predefined hardware library components. These components areconfigured to respond to the enable_in and enable_clr signals andgenerate the enable_out signal as described below. In anotherembodiment, the functionality of the structures and functions isspecified in the hardware description generated by the back end ratherthan by referencing a library component. In this case, the descriptiongenerated by the back end includes functionality for the enable_in,enable_out, and enable_clr signals.

The enable_in port receives an input signal signifying when the inputdata for a component is valid. Each component is responsible formonitoring the enable_in input. Each component delays the enable_ininput for as many clock cycles as necessary to perform the computationand then drives the enable_out signal to indicate that the output fromthe component is valid. Enable_in and enable_out are level-triggeredsignals. Once enable_out is asserted for a component, it remainsasserted until the enable_clr signal is asserted. When this occurs, theenable_out signal is deasserted.

The enable_in, enable_out, and enable_clr VPorts are added to the portmaps of each VComponent by the message handler function for eachcomponent in step 452 of FIG. 12. VSignal data structures are added torepresent the signals connected to these ports. Each wire that appearsin the graphical program is also associated with an enable signal. Whenthe data carried by the wire is valid the associated enable signal isactive high. For signals that drive components, the enable signal isconnected to the enable_in port of the components. For a component thathas multiple input signals, all of the enable signals associated withthe input signals are AND'd together to drive the component's enable_insignal. This AND is represented in the VDiagram with a VAssignment, andthe VComponent has a pointer to the VAssignment.

Enable_in, enable_out, and enable_clr ports are also added to thetopportmap of each VDiagram. These ports are master enable ports for theentire VDiagram. The VDiagram's enable_in port is routed to theenable_in ports of all the VComponents in the VDiagram's complist. Thismaster enable_in signal is AND'd together with the enable signalsassociated with any input signals the component has. Similarly, themaster enable_out signal for the VDiagram is driven by ANDing togetherthe enable_out signals for the VComponents. The VDiagram's masterenable_clr signal is routed to the enable_clr ports for all of theVComponents.

The enable ports for child VDiagrams associated with while loops and forloops are driven by the corresponding structure controller. FIG. 20illustrates how the structure controller drives the enable ports for aVDiagram representing a while loop subframe. The structure controllerhas its own master enable signals. It also sends enable signals based onthe execution state (e.g., iteration count) to the master enable signalsfor the child VDiagram's srnholder. Although not shown in the figure,the master enable signals of the smholder map directly to the masterenable signals of the child VDiagram.

The enable chain for a case structure is slightly different. The casecontroller decodes its select input and asserts an enable_in signal foronly one of its child VDiagrams. The case controller's subdiag_en outputsignal is a vector type, with one bit for each child VDiagram. Thevector is one-hot encoded and each bit is routed to the enable_in of aspecific child VDiagram. The subdiag_done input is a single-bit signaland is driven by the logical OR of all of its child VDiagram'senable_out outputs. The schdiag_clr signal is routed to all childVDiagrams.

Sequence structures are unique because they do not use a structurecontroller. Instead, a sequence is treated as a normal component and isfitted into the enable chain in the standard way. The only difference isthat the srnholder for the first frame in the sequence receives all ofthe enable_in fan-in signals for the entire sequence. The srnholder forthe last frame in the sequence produces the enable_out signal for allVComponents that depend on any output of the sequence. All intermediatesequence frame srnholders simply connect their enable_out outputs to theenable_in input of the next frame. This ensures that the frames of thesequence structure execute in hardware in exactly the same order as theywould in software.

FIGS. 21-26: Resources and Arbitration

Many programs that are converted into hardware require hardwareresources external to the programmable logic device (PLD). Hardwareresources include A/D converters and digital I/Os. Resources alsoinclude primitives that move data between the PLD and the CPU, such asglobal variable registers and DMA transfer primitives. A system isneeded to represent the hardware resource requirements in a VDiagramtree. Often, the same resource is used in many places in the hierarchyof VDiagrams in the VDiagram tree. Therefore a system of arbitration isalso needed to manage multiple simultaneous accesses to the sameresource. This section describes the systems used to represent andarbitrate hardware resources in the VDiagram tree.

Interfacing external hardware resources with a PLD requires coordinatingthe external resources with resources of the PLD. For example, differentexternal resources require a connection to specific pins on an FPGA. Asexamples, global variable registers need to access the external addressand data bus, and A/D converters need access to the data and controlsignals for a specific A/D channel. Such specific resources are onlyavailable from the level of the root VDiagram. Thus, resources are onlyinstantiated in the top-level VDiagram. As child VDiagrams areconstructed, they consolidate their resource information with theirparent VDiagrams so that the top-level VDiagram has all the informationnecessary to instantiate resources for the entire hardware description.

Each place where a specific resource is used in a VDiagram is called anaccess point. A resholder data structure (a type of VComponent) is addedto the VDiagram's complist for each access point of a specific resource.Resholders can be of type read-only, write-only, or read-write. Theseresholders route the data and enable chain signals from each accesspoint up through the parent VDiagram to the top-level VDiagram, wherethe individual requirements are arbitrated and fed into the childVDiagrams containing the resource-requiring VComponents.

Each VDiagram also has a resourcelist, which is a linked list ofVResource objects. Each VResource represents a specific hardwareresource. There may be many resholders for multiple access points for asingle resource in a VDiagram, but the resource is represented only oncein the resourcelist. Each VResource object maintains a list of read-typeresholders and a list of write-type resholders.

FIG. 21 illustrates an example program hierarchy in which the sameglobal variable is read in one subprogram and written in anothersubprogram. The process of building a VDiagram tree which requiresexternal resources is described here for the example program hierarchyof FIG. 21. This example will focus on the information added to theVDiagrams to represent the external resources. As shown in step 452 ofFIG. 12, the VDiagram constructor calls a message handler function toadd information for each object to the VDiagram. As explained above,child VDiagrams are added to the VDiagram in a depth-first traversalorder of the graphical program hierarchy. We thus start with subprogramnumber 2. Subprogram number 2 reads global variable “a”. Thus, themessage handler unction that adds the information representing theglobal variable object to the Diagram adds a read-type resholder to theVDiagram. The read-type resholder has a data output signal for the valuethat is read from the hardware resource (the global variable register inthis case). The resholder also has the normal enable_in and enable_clrinputs and the enable_out output. In addition, it has two special portscalled RES_RI and RES_RO. These abbreviations stand for “resource readinput” and “resource read output”. The resholder bundles its normalinputs and outputs into a read group and a write group and connectsthese bundles to the RES_RI and RES_RO ports, respectively. Since thisVDiagram is not the top-level VDiagram, ports are created on theVDiagram's topportmap to pass the resholder's RES_RI and RES_RO data upto the next level VDiagram. FIG. 22 illustrates the hardware representedby the VDiagram for subprogram 2.

After the global variable object's message handler function adds theread-type resholder for the read access point, it also adds a VResourceobject to the VDiagram's resource list. The address of the resholder isadded to the VResource's list of readers. Since in this example thereare no other access points for the global variable “a,” no other entriesappear in the VResource's lists of resholders.

After the global variable object's message handler function completes,step 452 of FIG. 12 continues as expected, calling message handlers forthe incrementer function and wire shown in subprogram 2. As shown inFIG. 12, the next step 454 adds routing information for the resources tothe VDiagram. VPorts are added to the topportmap of the VDiagram to passthe resource RES_RI and RES_RO signals between the VDiagram and itsparent VDiagram. There is only one resource in the VDiagram'sresourcelist and that resource only has one resholder. Thus, only twotop-level ports are needed. After the two top-level resource VPorts arebuilt, VSignals are added to connect the top-level VPorts to the RES_RIand RES_RO ports on the resholder VComponent.

As previously noted, VPorts of a child VDiagram are copied to thesrnholder's port map. The port numbers assigned to the resource ports ofthe resholders are recorded. The parent VDiagram can use thisinformation to route the resource signals through the appropriate portsin the srnholder to reach the appropriate resource access points.

Step 456 of FIG. 12 executes normally. This step does not need to doanything special to handle resources.

Step 458 of FIG. 12 consolidates the resource information in theVDiagram's resourcelist with the parent VDiagram's resourcelist. At thispoint, any access points in the portion of the program represented bythe parent VDiagram have not yet been identified. However, the resourceinformation for each child VDiagram is consolidated as step 458 isperformed for each child VDiagram. Resource information for the parentVDiagram's own access points is added when the steps of FIG. 12 arecarried out for the parent VDiagram.

The VResources of the child VDiagram that is constructed first aresimply copied into the parents VDiagram's resourcelist. For other childVDiagrams, if the parent resourcelist already has a VResource with thesame resource ID as the child's VResource, a complete copy is notperformed. Instead, the linked list of resholder pointers in the child'sVResource is merged into the linked list of the parent's VResource. Aseach child VDiagram is built and performs step 458, the top-levelVDiagram eventually ends up with the complete set of resourceinformation for the entire VDiagram tree.

Once resource consolidation is finished, the VDiagram constructor forsubprogram 2 returns. The depth-first traversal of the graphical programhierarchy continues with subprogram 4. The only major difference in theconstruction of VDiagrams for subprogram 2 and subprogram 4 is the typeof resholder that is created. Since subprogram 4 writes to the globalvariable “a,” a write-type resholder is added to the VDiagram fromsubprogram 4 instead of a read-type resholder. FIG. 23 illustrates thehardware represented by the VDiagram for subprogram 4.

Steps 452, 454, 456, and 458 are performed to build the VDiagram forsubprogram 4 as described above for subprogram 2. Step 458 merges theVResource object for the global variable “a” into the resourcelist ofthe parent VDiagram (the VDiagram for subprogram 3). As described above,the write-type resholder for the write access point in subprogram 4 iscontained in the VResource's list of write-type resholders.

The depth-first traversal continues with the construction of theVDiagram for subprogram 3. Since subprogram 3 does not have any accesspoints, no new resource data structures are added. However, step 454 isslightly different for subprogram 3 than for subprograms 2 and 4.Because there are no access points for this VDiagram, the only resourceinformation in the resourcelist is the global variable “a” VResourcethat was inherited from the VDiagram for subprogram 4. The VDiagramconstructor function can determine that this VResource was inheritedfrom a child VDiagram by checking the srnholder fields of the resholdersin the VResource's linked lists. The srnholder field contains a pointerto the srnholder of the VDiagram from which the resholder was inherited.If the srnholder field is not null, then the resholder in question is aresholder of a child VDiagram. Thus in step 454 when routing informationfor the resource signals is added, the port map of the srnholder of theappropriate child VDiagram can be searched to find the correct ports toconnect the resource signals to. (As noted above in the description forstep 454 for subprogram 2, the port numbers assigned to the resourceports of resholders are recorded.)

FIG. 24 illustrates the port connections added to the VDiagram forsubprogram 3 (referred to as VDiagram 3 ) during step 454 of FIG. 12.Note that ports from the port map of the srnholder for VDiagram 4 arereassigned to ports on the top-level portmap of VDiagram 3. In thisexample the port numbers do not change between VDiagram 4 and VDiagram3. If VDiagram 3 had another srnholder exactly like the one for VDiagram4, the resource ports from that srnholder would get mapped to othertop-level port numbers on VDiagram 3, e.g., 0×80000002 and 0×80000003.Thus it is possible for a resource to change port numbers as itpropagates up the VDiagram tree.

After generating the ports and signals to connect the srnholder forVDiagram 4 to the port map of VDiagram 3, step 454 of FIG. 12 updatesthe port number information for resholders whose port numbers werereassigned. (There were no reassignments in this case.) Also, thesrnholder field is updated to point to the srnholder for VDiagram 3.This will enable the VDiagram constructor for the top-level VDiagram todetermine that resource was inherited from VDiagram 3.

The fields that hold the srnholder and portnumber pointers may getoverwritten every time step 454 executes. It is not necessary topreserve this information. If the mapping for a resource at anyparticular level in the VDiagram tree needed to be determined, it wouldbe possible to compare the fields for the VResource entry in a parentVDiagram with the fields for the VResource entry representing the sameresource in a child VDiagram.

After step 454 of FIG. 12 completes for VDiagram 3, step 456 proceedsnormally. Step 458 then copies the same resource information that wasinherited from VDiagram 4 up to VDiagram 1. VDiagram 1 already has aVResource in its resourcelist for global variable “a” which wasinherited from VDiagram 2. The information about the write-typeresholder for VDiagram 4 is merged into the resholder list of theexisting VResource.

The execution of the steps of FIG. 12 is a special case for VDiagram 1because VDiagram 1 is the top-level VDiagram. Instead of routingresource ports from srnholders to the toplevel port map, the VDiagramconstructor builds VComponents for the resources themselves and connectsthem to the srnholder ports that feed back to the resholders. In thisexample, a globreg component is created for the global variableregister. The globreg register component is then connected to theexternal address and data bus ports. Next, the VDiagram constrctordetermines whether any arbitrators are necessary to multiplex multipleaccess points of the same type. If there are zero read or write accesspoints for a given VResource, then the read or write inputs to theresource VComponent are driven with all zeroes. If there is only oneread access point then the read ports of the resource VComponent can beconnected directly to the resource ports of the read-type resholder.Similarly, if there is only one write access point then the write portsof the resource VComponent can be connected directly to the resourceports of the write-type resholder. In the example program hierarchy ofFIG. 21, there is only one read access point and one write access point.Thus no arbitrators or zero-drivers are necessary in this example. FIG.25 illustrates the ports, components, and connections that are generatedby the VDiagram constructor for VDiagram 1.

Step 454 for a top-level VDiagram determines the type of each resourceand adds an appropriate library component reference to the VDiagram. Ifthe component requires any special signals, such as an address decodesignal, they are also added. For a global variable register, the addressdecode for the globreg is constructed using a VADecNode-typeVAssignment. Addresses may be assigned to globregs based on the order inwhich they are built. For example, a variable that stores the next validaddress may be incremented each time a globereg is built.

If there is more than one read or write access point for an individualresource, the top-level VDiagram constructor adds arbitrators to thetop-level VDiagram to manage the multiple accesses. FIG. 26 illustratesthe ports, signals, and components that are created to manage a globalvariable resource with two read and two write access points. Arbitratorshave wide inputs and outputs on the resholder side and narrow inputs andoutputs on the resource side. The wide inputs accommodate the array ofdata generated by concatenating the resource signals from multipleaccess points together.

The JOIN operators shown in the diagram are built using VALogicNodeswith the operation parameter set to a value specifying that the signalsshould be concatenated. This produces an assignment statement signifyingthat the destination signal is driven by the concatenation of all of theinput signals. The SPLIT operator is built using a VASliceNode. Thisproduces an assignment statement signifying that the destination signalis driven by a specific bit range of the source signal.

Additional Information

The above explanation describes the basic system and method of thepresent invention. This section provides additional informationregarding step 452 of FIG. 12, in which message handler functions arecalled for each object in the portion of a program represented by aVDiagram. Different message handlers are called for different types ofobjects. As described above, these message handler functions addinformation and data structures to the VDiagram in order to representthe respective objects in hardware. The following information applies tomessage handler functions for particular types of objects.

DiagOSaveHWInfoMethod

This is the message handler function for the root object of the entireblock diagram (graphical program). This is the first OSaveHWInfoMethodcall generated in step 452 of FIG. 12. This function does not addanything to the VDiagram. Instead, it generates more OSaveHWInfo callsfor all of the nodes on the block diagram, and then all of the signalson the block diagram. This order is important. Signals cannot beproperly processed until all of the components they connect to have beenadded to the VDiagram.

Note that specific graphical program components and constructs arediscussed are discussed below, such as sequence structures, casestructures, loops, loop tunnels, shift registers, etc. For moreinformation on these concepts, please see the above-referenced patentsor the LabVIEW documentation available from National Instruments.

SignalOSaveHWInfoMethod

This function creates a VSignal object to represent a signal appearingin a graphical program and inserts it into the VDiagram's signallist.Then, it builds a terminal list of VSigterm objects that point toVComponents. This terminal list is built using the information stored inthe root object representing the signal in the graphical program.Information is also included in the VDiagram to build the enable chainas described above.

SignalOSaveHWInfoMethod determines the type of connection for all of thesignal's terminals. There are three major types of connections:

1. SRN Connection

The signal attaches to an SRN object. This can be any of the following:

a) Front Panel Control or Indicator

These connections appear as ports on the VDiagram's topportmap. AVALogicNode assignment statement is generated to drive the signal withthe signal attached to the port. No enable chain logic is generatedbecause all front panel controls are valid when the subprogram isexecuted, and all components are automatically dependent on thesubprogram's enable_in signal. Likewise, the subprogram is automaticallydependent on all of its components' enable_out signals. Thus, signalsthat drive Front Panel Indicators do not generate any extra enable chainlogic.

b) Tunnel, Right Shift Register, or Sequence Local

These connections appear as ports in exactly the same way that frontpanel controls and indicators do. No enable chain logic is generated forthe same reasons as above. These connections are separate from the frontpanel controls and indicators because the front panel objects may bestored in the graphical program differently than tunnels, shiftregisters, and sequence locals.

c) Left Shift Register

A left shift register is a VComponent in the VDiagram's complist. AVSigterm is added to the signal to indicate that the signal is connectedto the data port of the left shift register VComponent. The enable_outof the left shift register VComponent is used to drive the enable chainfor this signal.

2. While, For, or Case connection

The signal attaches to a programmatic structure component from theoutside. Normally, this means a connection to a port on the loopsrnholder. A VSigterm is added to the signal to indicate that the signalis connected to a specific port of the loop srnholder. If the signaldrives a loop input, then the signal is considered to be an enabledependency for the loop. SignalOSaveHWInfoMethod calls AddEnvDependencyon the loop's srnholder to add the current signal's enable signal to thesrnholder's dependency list. If the signal is driven by a loop output,then the structure controller's enable_out is used as the enable for thesignal. There are two special cases where additional logic needs to becreated here:

a) If the signal drives the Maximum Iteration node of a For loop, thesignal is routed to the For loop's srnholder and also to the structurecontroller for the For loop. Two VSigterms are added to the signal. Thisensures that the maximum iteration value is accessible not only to thestructure controller, but to the components inside the for loop as well.

b) If the signal drives the Case Select input of a Case structure, thesignal is routed to each of the case's srnholders and also to thestructure controller.

Multiple VSigterrms are added to the signal. This ensures that theselect input is accessible to both the case structure controller andalso the contents of every frame in the case structure.

3. A Normal Component Connection

In this case, the signal attaches to a normal component such as an adderor a multiplier. These components are VComponents in the VDiagram. AVSigterm is added to connect the signal to a specific port of theVComponent. If the signal drives one of the component's inputs,AddEnvDependency is called for that VComponent. If the signal is drivenby one of the component's outputs, the VComponent's enable_out is usedas the enable for the signal.

SRNOSaveHWInfoMethod

Self reference node (SRN) is the term used to signify the internalobject maintained by the graphical program system which groups togetherthe objects contained in a program, subprogram, or subframe. Theseinclude objects such as constants, shift registers, tunnels, sequencelocals, wires, subprograms, programmatic structures, etc. This functiondoes not add any objects to the VDiagram tree. Instead, it generatesmore OSaveHWInfo calls for the objects it contains.

FPTermOSaveHWInfoMethod

This function does not add any objects to the VDiagram tree. Instead, itgenerates a single OSaveHWInfo call to the front panel control orindicator object it points to.

FPDCOOSaveHWInfoMethod

This function is the target of the OSaveHWInfo call inFPTermOSaveHWInfoMethod. Front panel controls and indicators arerepresented as ports on the VDiagram's topportmap. This function adds aport for a front panel object to the VDiagram's topportmap only if it iswired to the connector object of the program. Unwired front panelobjects are left floating. After the port is created, a VSignal of theappropriate width is attached to the port. Signals that attach to thefront panel control or indicator then get attached to this new signal bySignalOSaveHWInfoMethod.

TermOSaveHWInfoMethod

This function is the target of the OSaveHWInfo calls made bySRNOSaveHWInfoMethod. This function does not add any objects to theVDiagram tree. Instead, it generates a single OSaveHWInfo call to theconstant, shift register, tunnel, or sequence local that the terminal isassociated with. This function translates OSaveHWInfo calls fromterminals on an SRN's object list to the actual objects the terminalsare attached to.

BDConstDCOOSaveHWInfoMethod

A constant is represented in the VDiagram tree as a VSignal of typeV_CONST. A new VSignal is created with the appropriate initializationvalue and added to the VDiagram's signallist.

RSROSaveHWInfoMethod

This function processes a right shift register and all of its attachedleft shift registers. One left shift register VComponent is added to theVDiagram for each left shift register in the shift register chain.Signals are created to propagate the data along the shift registerchain. VSigterms for these signals are created to link all of the leftshift register VComponents together. If any of the left shift registersare initialized, ports are added to the VDiagram's toplevel portmap tosend that data into the VDiagram. Then VSignals and VSigterms arecreated to attach the ports to the initialization inputs of each leftshift register VComponent. If a signal is attached to the right shiftregister from outside the loop, a VDiagram port is created to pass theshift register data to the parent VDiagram. Otherwise, the right shiftregister is treated simply as an internal signal that drives theshift_in data port of the first left shift register in the shift chain.

LSROSaveHWInfoMethod

Because RSROSaveHWInfoMethod builds all of the VComponents for the leftshift registers, this function does not need to do anything.

SLocOSaveHWInfoMethod

This function processes a sequence local. Sequence locals are treated asports on the VDiagram's portmap. The same sequence object will get aSLocOSaveHWInfoMethod call for each frame in the sequence structure. Itis important to not generate ports for the sequence local until theframe where the local is driven. SLocOSaveHWInfoMethod checks for thisand will not add ports if the sequence local is not driven in thecurrent VDiagram. In all sequence frames after the local is driven, aport will be created regardless of whether the local is read or not.Only ports are created in the function. SequenceOSaveHWInfoMethod willgenerate the VSignals that propagate the local between frames.

SeqTunOSaveHWInfoMethod SelTunOSaveHWInfoMethod LpTunOSaveHWInfoMethod

These three methods generate loop tunnels in similar ways. Loop tunnelsare represented in hardware as ports on the VDiagram they belong to.Each of these functions generates a new VPort for the VDiagram'stopportmap and attaches a new VSignal to that port. Any future signalthat connects to the tunnel will either drive or be driven by this newVSignal by a VAssignment object. External multiplexers for Case outputtunnels are not generated in this function. They are built inSelectOSaveHWInfoMethod. Sequence tunnels that are outputs only becomeports on the VDiagram frame in which they are driven. Sequence inputtunnels are turned into ports on all VDiagram frames.

CaseSelOSaveHWInfoMethod

This method processes the case select input node of a case structure.This node becomes an input port on each VDiagram belonging to the case.This allows the components inside the case frames to use the selectinput as a data source.

LMaxOSaveHWInfoMethod

This method processes the maximum iteration node of a For loop. Thisnode becomes an input port on the VDiagram belonging to the For loop.This allows the components inside the loop to connect to the maximumiteration node. On the outside of the loop, the signal that drives thisnode attaches both to the new VDiagram port and also to the maximumiteration port on the For loop structure controller.

LCntOSaveHWInfoMethod

This method processes the iteration counter node for while loops and forloops. This node becomes an input port on the VDiagram corresponding tothe loop subframe. On the outside of the loop, this port is driven bythe loop structure controller's iteration count output.

LTstOSaveHWInfoMethod

This method processes the continue node for a While loop. This nodebecomes an output port on the VDiagram corresponding to the loopsubframe. On the outside of the loop, this port drives the While loopstructure controller's continue input.

PrimOSaveHWInfoMethod

This method processes functions, such as adders, comparators, datamanipulation operators, type converts, etc. This function adds a newVComponent to the VDiagram's complist. Clock, reset, and enable chainports are added to the new VComponent. Then, generic parameters and dataports are added to the new VComponent. The exact ports and generics thatare added depend on the type of the function. Numeric functions haveWIDTH and REPRESENTATION generic parameters. Comparison functionstypically have WIDTH-based inputs, but only single-bit outputs. Otherfunctions such as Split, Join, Scale, and Select have slightly morecomplicated generic parameters and data ports.

GRefOSaveHWInfoMethod

This method processes references to global variables. This function addsa new resholder VComponent to the VDiagram's complist. If the referenceis a global variable read, a read-type resholder is created. Awrite-type resholder is created for global variable writes. Clock,reset, and enable chain ports are added to the resholder VComponent. Ageneric parameter for the data width is also added. Lastly, the functioncreates a new VResource object to represent this resource access pointand adds it to the VDiagram's resourcelist. If a VResource alreadyexists for the global variable, the new resholder is automaticallyconsolidated into the existing VResource.

IUseOSaveHWInfoMethod

This method processes references to subprograms. A srnholder componentis created and added to the VDiagram's complist. The srnholder is givenclock, reset, and enable chain connections. Then, a new VDiagram objectis constructed for the referenced subprogram. This new VDiagram is addedto the current VDiagram's subvilist. Once the child VDiagram is built,its topportmap is copied into the srnholder's port map. This ensuresthat the subVDiagram and the srnholder have the same port map.IUseOSaveHWInfoMethod treats all subprograms as re-entrant and makesunique VDiagrams for each instance of a subprogram.

WhileLoopOSaveHWInfoMethod

This method processes While loops. A srnholder component is created forthe While loop and added to the VDiagram's complist. Then, a newVDiagram object is constructed. The loop subframe is used as the rootnode for building the child VDiagram. The child VDiagram is added to theparent VDiagram's srnvilist. After the child VDiagram is built, itstopportmap is copied into the srnholder's port map. This ensures thatthe subVDiagram and the srnholder have the same port map. The smholderVComponent is given clock and reset signals. A While loop structurecontroller is created and added to the VDiagram's complist. Thestructure controller is given clock, reset, and enable chain signals. Itis also given subdiagram enable signals (subdiag_en, subdiag_done,subdiag_clr), and these signals are given VSigterms to attach them tothe loop srnholder. The structure controller points to the srnholder.The srnholder points to the subVDiagram.

ForLoopOSaveHWInfoMethod

This method processes For loops. It functions similarly to theWhileLoopOSaveHWInfo method. The For loop structure controller has aparameterized input width for the maximum iteration input so that themaximum iteration node can be driven by a signal of any integer type.

SequenceOSaveHWInfoMethod

This function builds srnholders and child VDiagrams for each frame inthe sequence. These child VDiagrams are added to the parent VDiagram'ssubsmlist. However, no structure controllers are built. The sequenceframe srnholders are given clock, reset, and enable chain signals. Aseach sequence frame srnholder is built, the enable_out signal from theprevious frame is set as an enable dependency for the current frame.This ensures that the sequence frames execute in sequence regardless ofwhether they share any data or not. After child VDiagrams are built forthe sequence frames, SequenceOSaveHWInfoMethod processes sequencelocals. Each sequence local appears as a port on one or more of thechild VDiagrams. These ports are connected together with a VSignal. Foreach sequence local in a sequence, a VSignal of the appropriate width iscreated and added to the VDiagram's signallist. Then, VSigterms arecreated to attach the new signal to each of the frames the sequencelocal connects to.

SelectOSaveHWInfoMethod

Similarly to SequenceOSaveHWInfoMethod, this function builds srnholdersand child VDiagrams for each frame in the case structure. These childVDiagrams are added to the parent VDiagram's subsrnlist. A structurecontroller is built. The case structure controller has parameterizedports for the width of its select input and the number of case frames itcontrols. The case controller is also given clock, reset, enable chain,and subdiag enable chain ports. The subdiagram enable signals are routedto the srnholders in a special way. The subdiag_en signal is a widesignal with one bit for each case frame. Frame 0 uses subdiag_en(0) asits enable_in. Frame 1 uses subdiag_en(1) as its enable_in, etc.Subdiag_clr is wired to the enable_clr input of all the srnholders. Theenable_out outputs of all the smholders are OR'd together using aVALogicNode assignment to drive the subdiag_done input of the casecontroller. SelectOSaveHWInfoMethod builds multiplexors for the casestructure's output tunnels. Each output tunnel is driven by a VAMuxNodeassignment. This ensures that only the outputs of the currently selectedcase frame can be used outside of the case structure. The casecontroller's subdiag_en signal is used as the select signal for alloutput multiplexors. When subdiag_en(0) is active high, each outputtunnel multiplexor will select the outputs of case frame 0. Whensubdiag_en(1) is active high, each output tunnel multiplexor will selectthe outputs of case frame 1, etc. Each case output tunnel is driven byevery case frame. Thus, SelectOSaveHWInfoMethod assumes that eachmultiplexor will have the same number of inputs. The hardwaredescription syntax may be generated in such a way that implicitly causesthe last frame in the case to become the default.

FIGS. 27 and 28—Coordinating Data Flow with Host Processor

As described above, a portion of a graphical program may be converted toa hardware implementation, while another portion executes on the hostCPU. In most cases, data will flow between these two program portions.FIGS. 27 and 28 illustrate how this data flow is coordinated throughhardware resources. As noted above, external resources are only resolvedin the top-level VDiagram. All access points to external resources inchild VDiagrams are funneled up to the top-level VDiagram. Thus FIGS. 27and 28 are only relevant to the top-level VDiagram.

FIG. 27 illustrates tying in an output signal with the host processor.In step 500 the VDiagram constructor determines whether the outputsignal connects to an object in the portion of the graphical programexecuting on the host CPU or to an object internal to the hardwareportion of the program. As shown in step 506, if the signal connects toan object within the hardware portion, then a VSigterm or VAssignment iscreated to represent this connection in the usual way as describedabove.

If the signal connects to the CPU portion of the program, then in step502 the VDiagram constructor adds information to the VDiagram torepresent a hardware read register that the signal can connect to. Thishardware register receives the signal output as its data input, as shownin step 504. It also uses the enable_out of the signal as its enable_ininput, thus maintaining the proper execution order.

The CPU portion must also coordinate itself with the hardware portion.The graphical program system recognizes that the input for one of itscomponents originates from the hardware portion, and reads the readregister created in step 502 accordingly for the component's input. Thusthe system works together to seamlessly enable hardware programexecution.

FIG. 28 illustrates the process of FIG. 27 corresponding to an inputsignal from the CPU portion rather than an output signal to the CPUportion. If the signal is not from the host portion, then it is tied tothe output node of an internal component in step 514. If the signal isfrom the host portion, it is tied to a write register that the hostportion writes to.

FIG. 29—Generating VHDL from a VDiagram Tree

As previously noted, various back ends may parse the VDiagram tree andgenerate a hardware description from it. For example, the system maycomprise a VHDL back end to generate a VHDL hardware description, anEDIF back end to generate an EDIF hardware description, an XBI back endto generate a Java hardware description, etc. FIG. 29 is a flowchartdiagram illustrating how a back end may generate VHDL syntax for aVDiagram tree. In step 602, the VHDL back end generates VHDL text forall child VDiagrams of the top-level VDiagram that correspond tosubprograms. A VDiagram may have two types of child VDiagrams: childVDiagrams representing subprograms and child VDiagrams representingsubframes of programmatic structures such as while loops, casestructures, etc. These two types of child VDiagrams are maintained inseparate lists in the VDiagram (the subvilist and the srnlist,respectively). In step 602 the child VDiagrams that correspond tosubprograms are parsed and VHDL text is generated for them. The VHDL foreach subprogram VDiagram is preferably placed in a separate file, butmay also be generated into a single file.

In step 604, the VHDL back end generates VHDL text for the childVDiagrams representing programmatic structure subframes. The VHDL codefor each of these VDiagrams is generated into the same file so thatlocal components such as sequence frames stay together.

Steps 602 and 604 generate the VHDL code for the top-level VDiagram'schild VDiagrams. These steps occur before any VHDL code is generated forother components of the top-level VDiagram, such as signals orconstants. Thus the back end traverses the VDiagram tree in adepth-first manner. For each child VDiagram, the steps of FIG. 29 areperformed. If a VDiagram has no children, then steps 602 and 604 donothing and execution continues with step 606. The depth-first parsethrough the VDiagram tree ensures that the entity/architecture blockpair for a child VDiagram is written to an output file before theentity/architecture block pair for a parent VDiagram. This order is arequirement of many VHDL compilers.

In step 606 the VHDL back end generates the VHDL library includestatements.

In steps 608-616 the VHDL entity/architecture block pair for theVDiagram is generated. In step 608 the VHDL entity declarations forports connecting the VDiagram to its parent are generated. In step 610the VHDL entity declarations for components in the VDiagram's complistare generated. A message handler function is called for each type ofcomponent to generate these declarations. In step 612 the VHDLdeclarations for signals in the VDiagram's signallist is generated. Instep 614 the VHDL component instantiations for components in theVDiagram's complist are generated. A message handler function is calledfor each type of component to generate these instantiations. In step 616the VHDL assignment statements are generated.

Uploading a Hardware Implementation to the Programmable Logic

There are various possibilities or methods for uploading a hardwareimplementation to the programmable logic device. In one instance, thehost CPU merely uploads the configuration to the programmable logic asdescribed above. This could occur by the driver at boot up time or whenthe user presses the run button on the graphical program that wascreated. Alternatively, the host CPU provides the hardwareimplementation to a non-volatile memory comprised on the board, andduring boot up of the board this hardware implementation is loaded fromthe non-volatile memory on the board into the programmable logic.

Thus the reconfigurable board can be designed so that the hardwarediagram is written to non-volatile memory instead of directly to theFPGA. This allows a hardware implementation of a diagram to beginexecution at power-on (long before the operating system has finishedbooting). In this case, the program preferably has top-level enable_inand abort signals which can be configured at compile time to eitherallow immediate execution or to require a supervisory program to enablehardware execution.

Default Configuration for Hardware Simulation

As discussed above, in the preferred embodiment the system of thepresent invention comprises a computer system which includes or iscoupled to a device, such as an add-in card. The device preferablyperforms a data acquisition/generation function, e.g., is a dataacquisition card. The DAQ card includes D/A and A/D converters as wellas various other data acquisition logic, and includes a programmablelogic device such as an FPGA which is operable to receive a hardwareimplementation created in response to a graphical program created on thecomputer system.

In one embodiment of the invention, the programmable logic or FPGA isoperable to receive a default configuration, whereby the defaultconfiguration operates to configure the data acquisition board with astandard interface for execution of the graphical program in software.Thus, for example, the host CPU may upload a hardware implementation tothe FPGA which programs the FPGA with a default configuration of a boardto provide a desired interface for the board. This configuration wouldprovide the host computer with direct access to the I/O of the board.This is useful, for example in hardware simulation, to allow the hostCPU to execute the graphical program or diagram in software duringalgorithm development to determine feasibility and perform debuggingetc. The graphical program behaves the same as it normally would inhardware, except the program runs slower due to software execution.However, software debugging tools available in the graphical programmingsystem are available in order to more easily debug the program. Thisimplementation also provides a faster compile time thus allowing aquicker turnaround for user bug fixes. Thus, it is anticipated that theuser will upload a default configuration to the programmable logic andexecute the graphical program being created in software one or moretimes to facilitate debugging. Once the graphical program has beenconstructed to a satisfactory performance, then the user may upload theactual hardware implementation of the graphical program to theprogrammable logic as described above.

As discussed above, there are various possibilities or methods foruploading a default configuration to the programmable logic. In oneinstance, the host CPU merely uploads the configuration to theprogrammable logic as described above. This could occur by the driver atboot up time or when the user presses the run button on the graphicalprogram that was created. Alternatively, the host CPU provides thedefault configuration to a non-volatile memory comprised on the board,and during boot up of the board this default configuration is loadedfrom the non-volatile memory on the board into the programmable logic.

Estimation of the Size and Cost of a Hardware Implementation

In one embodiment of the invention, the graphical programming systemincludes a data structure which includes a listing of each of theelements or components comprised in the component library, as well asthe corresponding cost of each component in terms of gates and time ofexecution (FIG. 37, step 702). Thus, in this embodiment when a graphicalprogram is created, the graphical programming system operates toreference the data structure to obtain the associated gate and timecosts associated with each component being used from the componentlibrary in the graphical program being constructed (FIG. 37, step 704).For example, the graphical programming system totals the amount of gatesutilized with regard to each component being used in the graphicalprogram being constructed (FIG. 37, steps 706 and 708), and thendetermines if the programmable logic or FPGA being used has sufficientcapacity to implement that graphical program (FIG. 37, step 710). Also,the graphical programming system can use this data structure todetermine at or prior to compile time how fast the graphical programwill execute in hardware, i.e., how fast the hardware implementationwill execute in the FPGA (FIG. 37, step 712).

Alternatively, the graphical programming system receives user inputregarding desired execution time (FIG. 38, step 722) and utilizes theexecution times of each of the elements to provide feedback to the useras to whether the graphical program satisfies the users requirementsregarding time of execution (FIG. 38, steps 724 and 726).

In addition, in one embodiment the component library includes multipleversions of respective components. For example, the component libraryincludes a fast multiplier that is large and a small multiplier that isslow. The graphical programming system can be configured to select theappropriate version of component based on how much of the FPGA isconsumed by the rest of the diagram and based on the loop timesindicated in the diagram, or other input from the user and/orinformation in the diagram (FIG. 37, step 704). Thus, in one embodiment,the user inputs both the number of gates comprised in the programmablelogic being used as well as the desired time of execution, and thegraphical programming system automatically selects among variousversions of components in the component library, e.g., a slower and lesscomplex adder vs. a faster but more complex adder, in order to develop ahardware implementation which is suitable for the user's application.

In another embodiment, the user can select between parameter executiontime vs. deployment size. In other words, the user may have the optionto configure compilation time vs. optimization of the parameters above.Given the interactive and target customer of this system, compilationtime may be an important parameter, wherein the user may choose tooptimize compilation time over the parameters above.

Manipulation of Non-reuseable Hardware Resources

When a user creates a graphical program which manipulates one or morehardware resources of a device, such as one or more hardware resourcescomprised on an add-in board, e.g., a data acquisition board, in generalthe hardware device or board will have a limited number of hardwareresources or components that are useable by the graphical program. Forexample, a given data acquisition board may only have one analog inputchannel. At least a subset of these hardware resources may only be usedonce, i.e., are not re-useable, referred to as non-reusable components.Examples of hardware resources include A/D converters, D/A converters,timers, counters, clocks, input channels, output channels, filters, andother logic blocks.

In one embodiment of the invention, the non-reusable componentscomprised on the hardware being controlled appear on a palette duringconfiguration or construction of the graphical program. Morespecifically, icons representing these non-reusable components orhardware resources appear on a palette during configuration orconstruction of the graphical program. The icons representing thesenon-reusable components disappear as they are used by the diagram toindicate to the user that these components have been used and thuscannot be reused (FIG. 39, step 732). In one embodiment, the user simplydrags these non-reusable component icons from the palette into thegraphical program. Once these components are dragged from the paletteinto the graphical program, the component icon disappears from thepalette, and thus the user knows that the component has been used in thegraphical program and is thus not available for reuse.

Where two or more hardware resources or components are comprised on theboard which can be used, a corresponding two or more components appearin the palette. In this instance, as each component is used in thegraphical program, the corresponding picture in the palette disappearsto alert the user as to the number of remaining hardware componentswhich can be used (FIG. 39, step 732). This provides a convenientmechanism for providing information to the user regarding the hardwarecomponents used and prevents reuse of a non-reusable component.

In some graphical programs, it is often convenient for a singlegraphical program to access a single hardware element from severallocations in the graphical program or diagram. This would technicallyviolate the single instance or non re-useability concept discussedabove, whereby a non-reusable component can be used only once in agraphical program. However, where the user desires to access a singlenon-reusable hardware element in several places in a single graphicalprogram, the user preferably constructs sequencing or implementssequencing in the graphical program which prevents this hardware elementfrom being used simultaneously within the same graphical program (FIG.39, step 734). For example, in the LabVIEW program the user constructssequencing using a sequence structure. In one embodiment, references tohardware elements in the graphical program provide a “handle” to thehardware which is provided to the graphical program which can be used inmultiple locations within the graphical program. This reference or“handle” to the hardware can then be used to provide simultaneousaccesses to a single device in the graphical program.

In general, there are three different ways a graphical program ordiagram can be constructed to access unique hardware resources. In afirst instance (a) a single reference to the hardware appears in thediagram as discussed above. In a second instance (b) multiple referencesto the hardware appear in the graphical program, but no two of thesereferences occur simultaneously. For example, the user can figure thesemultiple references in different frames of a sequence structure. In athird instance (c) the graphical program includes multiple references tothe hardware, and the way in which the graphical program is constructedindicates that these multiple references may be executed simultaneously.

In the preferred embodiment, the graphical programming system preferablydetects which of the above cases exist and performs any necessary typeof configuration to accommodate these situations. In the first instanceof case (a), a single reference to the hardware appears in the graphicalprogram, and thus the graphical programming system is not required toperform any special processing in generating the hardwareimplementation. In the second case (b) mentioned above, the graphicalprogram, when converting the sequence structure to a hardwareimplementation, utilizes multiplexers to multiplex the control and datainputs to the hardware in question with the same signals to guaranteethat simultaneous accesses are impossible, as indicated by the sequencestructure. In case (c) above, the graphical programming systempreferably automatically detects an instance where multiple referencesin the hardware appear, wherein they may be executed simultaneously, andconfigures the hardware implementation to prevent these multipleaccesses, and thus thereby preventing possible erroneous operation. Inthis instance, the graphical programming system, during the conversionprocess to the hardware implementation, detects the multiple referencesto the hardware which can be executed simultaneously, and instantiatesone or more multiplexers and a full arbitration circuit to control themultiplexers. The multiplexers are provided in the hardwareimplementation to prevent or avoid the possibility of simultaneousexecution of these multiple references to the non-reusable hardware.

In cases (b) and (c), the hardware implementations use similarmultiplexers. The difference between cases (b) and (c) is that in case(c) the hardware implementation includes a control circuit. In case (b)the control signals are the same control signals that control whichframe of the sequence is executing, and in (c) the control signals comefrom an arbitration circuit. Also, in item (b), the multiplexers thatconfigure and implement the sequence structure are set or defined atcompile time. Alternatively, in case (c) the arbitration unit is notnecessarily defined as far as ordering at compile time, but the order ofexecution is actually defined at run time.

Probe Insertion

In one embodiment, during creation of the graphical program, a user mayinsert one or more probes into the graphical program which operate todisplay data on the respective wire where the probe is located duringexecution of the graphical program. When the user inserts a probe in oneor more locations in the graphical program, the programmable logic orhardware element is configured with an element, referred to generally asa probe element, to display the appropriate value during execution ofthe programmable logic, much the same way a probe placed in a graphicalprogram is used to display a value during execution of the graphicalprogram. Thus the probe element may provide a real-time view andobservability into the programmable logic or FPGA. Examples of the probeelement include a time stamp generation circuit a register, or othertype of memory or circuit for implementing a probe function.

In one embodiment, when the user inserts a probe in one or morelocations in the graphical program, the corresponding hardwareimplementation directs the use of a time stamp generation circuit. Inother words, when the user inserts a graphical icon of a probe in one ormore locations in the graphical program, the programmable logic isconfigured to include a time stamp generation circuit. The time stampgeneration circuit may be used to produce a value for a memory in theprogrammable logic associated with the location in the graphical programwhere the probe was inserted. The time stamp generation circuitpreferably produces a value for the memory when the value changes. Moreparticularly, the time stamp generation circuit preferably produces avalue/time pair value of a memory location at the time of transitionwhen the value changes.

The time stamp generation circuit may be included inside theprogrammable logic or FPGA, or the time stamp generation circuit isconfigured in a separate chip or logic block included on the board whichis coupled to the FPGA. This time stamp generation circuit allows thegraphical programming system to insert probes into the hardwareimplementation of the graphical program or diagram. The time stampgeneration circuit thus comprises a hardware implementation of the probewhich was inserted in the software graphical program. This enables thehardware debugging environment to look and feel the same as it does inthe graphical programming system. The time stamp generation circuitpreferably provides its output on a pin of the programmable logic, e.g.,the FPGA.

In an alternate embodiment, when the user inserts a probe in one or morelocations in the graphical program, the corresponding hardwareimplementation directs the use of a register. In other words, when theuser inserts a probe in one or more locations in the graphical program,the programmable logic is configured to include a register. The registermay be used to store a value in the programmable logic associated withthe location in the graphical program where the probe was inserted. Theregister is preferably memory-mapped, and thus may be readable throughmemory mapped I/O.

The probe value obtained from the programmable logic or FPGA duringexecution of the programmable logic may optionally be sent to thegraphical user interface being executed and/or displayed by the host.Thus the probe value may be displayed on the display in the graphicalprogram, much the way a probe value is displayed in a software-executedgraphical program, e.g., LabVIEW.

In one embodiment, the system includes two compile modes referred to asdebug and release. The debug mode may support the inclusion of probes,or the automatic insertion of probes by the system without userspecification. After the product has been finalized, the probes mayoptionally be removed for release mode. The system may also include a“debug version” of the system or board with a larger FPGA and/orpossibly extra support for the time stamping, etc., such as buffers,external memory, etc.

Data Path Optimization

In one embodiment, the graphical programming system is operable todetect graphical programs or diagrams that are streaming data to/fromthe host computer, and the graphical programming system inserts specialcircuits in the hardware implementation to handle DMA for high speedtransfers without special consideration from the user. These circuitsinclude FIFOs and circuits to generate DMA requests (DRQ) or theequivalent.

This method enables the graphical programming system to automaticallygenerate a DMA circuit for the graphical program or diagram created bythe user. In the usual case, all communication to the graphical programor diagram from the CPU passes through global variables. According tothis embodiment, the diagram would include an icon which looks similarto a “write global” in the sense that it is a data sink. When the iconis executed, the icon would assert a DMA request (DRQ) that goes back tothe DMA controller and triggers a DMA transfer. The FIFO and DRQgeneration circuitry are built inside the FPGA when the DMA icon isused.

Occurrences

The LabVIEW graphical programming system includes an occurrencecapability which allows a first function to “go to sleep” while waitingfor a second function to produce a result. In this manner, the firstfunction does not consume any CPU time while waiting for the secondfunction. Three icons are provided with associated control softwarewhich implement the occurrence function. A Wait on Occurrence functionicon is associated with the first function that is waiting on the resultfrom the second function. A Set Occurrence function icon is typicallyassociated with the second function icon and triggers an occurrence whenthe second function produces the desired result. A Generate Occurrencefunction icon is used to pass identifier values linking multiple sourcesand destinations having Set Occurrence and Wait on Occurrence functionicons, respectively.

Occurrences share some of the properties of global variables in thattheir implementation depends greatly on whether they are “written” and“read” within a single environment (all in software, all in hardware, orcrossing the software/hardware boundary). An occurrence that is set anddetected within hardware involves set and detect occurrence componentsfrom the library. An occurrence that is set in hardware and detected bythe host CPU can be mapped automatically to an interrupt. The graphicalprogramming system, e.g., LabVIEW, would then generate the interrupthandling code to run on the host computer.

Automatic Generation of the Programmatic Interface

In one embodiment, the hardware implementation generated by thegraphical programming system, can be configured to be controlled byother software environments or other protocols, e.g., C, C++, Java,Visual Basic, Visual C++, LabWindows CVI, other types of graphicalprogramming systems, etc. In this embodiment, the graphical programmingsystem can automatically generate a description of the hardwarenecessary including a register map, interrupt map, DMA abilities, etc.to enable other software environments to control the hardwareimplementation. For example, in the preferred embodiment using theLabVIEW Graphical Programming System from National InstrumentsCorporation, the graphical program constructed in LabVIEW is convertedinto a hardware implementation, wherein the hardware implementation alsoincludes the above hardware information necessary to allow anothersoftware development environment to control or execute the hardwareimplementation.

Compensating for Poor Place and Route Results

As discussed above, the present invention preferably uses a third partytool which converts the netlist created from the graphical program intoa hardware implementation or FPGA configuration. In one embodiment, ifthis third party tool reports that the maximum clock speed is less thanexpected by the graphical programming system, then the graphicalprogramming system can optionally reduce the clock speed and adjust oneor more counter values and timers to compensate for this new clockspeed. This is preferably performed in cases where overall performancegoals are still met.

This may be necessary in instances, for example, where the user hasconfigured timing within the graphical programming system on theassumption of a certain clock speed, e.g., a timing loop which assumes a20 MHz clock and a loop constructed based on this 20 MHz clock thatloops for two milliseconds. In cases where the clock speed is less thanexpected, the hardware implementation may actually work differently thanexpected by the user due to this different clock speed. In thisinstance, the graphical programming system can automatically reduce theclock speed and adjust the counter values and respective timers tocompensate for this new clock speed and thus provide the user with theperformance that the user expected when he/she created the graphicalprogram. This embodiment utilizes a configurable oscillator on the dataacquisition board.

FIG. 30—Simple Graphical Program Example

FIG. 30 illustrates a simple example of a graphical program. In FIG. 30the graphical program includes three input terminals and one outputterminal. The graphical program simply comprises a first 2-input Addfunction node which receives input from two inputs terminals, and asecond 2-input Add function node which receives the output from thefirst Add function node and receives an output from the third inputterminal. The second 2-input Add function node provides an output tooutput terminal as shown.

FIG. 31—Hardware Result

FIG. 31 is a conceptual diagram of the resulting hardware after thegraphical program example of FIG. 30 is converted into a hardwaredescription. As shown, the hardware diagram includes three writeregisters 522-526 corresponding to each of the three input terminals.The data outputs of the first two write registers 522 and 524 areprovided as inputs to a first two-input adder 532, which corresponds tothe first adder in the block diagram of FIG. 14. The hardwaredescription also involves creating an AND gate 534 which receivescontrol outputs from each of the first two write registers 522 and 524and provides a single output to the control input of the adder 532. Thepurpose of the AND gate 534 is to prevent the adder 532 from executinguntil both inputs have been received.

The Adder 532 provides a data output to a second two-input Adder 542,which corresponds to the second adder in the block diagram of FIG. 14.The first Adder 532 also generates an enable out signal which isprovided to an input of a second AND gate 536. The other input of theAND gate 536 receives an output from the third write register 526,corresponding to the third input terminal. The AND gate 536 provides anoutput to a control input of the second adder 542. Thus, the AND gate536 operates to ensure that the second adder 542 does not execute untilall inputs have been received by the adder 542. The second adder 542provides a data output to a read register 546 associated with the outputterminal. The second adder 542 also provides an enable out signal to theread register 546, which notifies the read register 546 when valid datahas been provided.

Thus, as shown, to create a hardware description for each of the inputterminals, the flowchart diagram of FIG. 12 is executed, which operatesto create a hardware description of a write register 522, 524, and 526,each with data and control outputs. For each adder function node, ahardware description of an adder 532 or 542 is created, and anassociated N input AND gate 534 or 536 is created, with inputs connectedto the dependent inputs of the adder function node to ensure executionat the proper time. The flowchart diagram of FIG. 27 is executed for theoutput terminal of the graphical program, which operates to generate ahardware description of a read register with data and control inputs.

FIGS. 32-34: Example of Converting a Graphical Program into a HardwareImplementation

FIGS. 32-34 comprise a more detailed example illustrating operation ofthe present invention.

FIG. 32 illustrates an example graphical program (a LabVIEW diagram)which is converted into an FPGA implementation using the presentinvention. As shown, the graphical program comprises a plurality ofinterconnected nodes comprised in a While loop. As shown, the While loopincludes shift register icons, represented by the down and up arrows atthe left and right edges, respectively, of the While loop. A 0 constantpositioned outside of the While loop is connected to the down arrow ofthe shift register at the left edge of the While loop.

The While loop includes a timer icon representing or signifying timingfor the While loop. The timer icon includes inputs for period and phase.As shown, the timer icon receives a constant of 1000 for the period andreceives a constant of 0 for the phase. In an alternate embodiment, theWhile loop includes input terminals which are configured to receivetiming information, such as period and phase.

FIG. 33 illustrates the LabVIEW data structures created in response toor representing the diagram or graphical program of FIG. 32. The datastructure diagram of FIG. 33 comprises a hierarchy of data structurescorresponding to the diagram of FIG. 32. As shown, the LabVIEW datastructure representation includes a top level diagram which includes asingle signal connecting the 0 constant to the left hand shift registerof the While loop. Thus the top level diagram includes only the constant(0) and the While loop.

The While loop includes a sub-diagram which further includes left andright shift register terms, the continue flag of the While loop, aplurality of constants, a timer including period and phase inputs,global variables setpoint and gain, sub-VIs a/d read and d/a write, andvarious function icons, e.g., scale, add, subtract, and multiply.Further, each of the objects in the diagram have terminals, and signalsconnect between these terminals.

As described above, a VDiagram tree is constructed which represents thehardware components and the relationship among them required to convertthe program into a hardware implementation. The VDiagram constructor iscalled for the “Diag” root object of the diagram, shown in FIG. 33. TheVDiagram constructor calls a message handler function for each of theobjects shown in FIG. 33. Once the VDiagram tree is built, a back endprogram is called to generate a hardware description using theinformation in the VDiagram tree.

FIG. 34 illustrates a circuit diagram representing the hardwaredescription which is created in response to the data structures of FIG.33. The circuit diagram of FIG. 34 implements the graphical program ofFIG. 32. As shown, the CPU interface signals are bussed to the globalvariables. Although not.shown in FIG. 34, the CPU interface signals arealso provided to the subprograms a/d read and d/a write.

The While loop is essentially abstracted to a control circuit whichreceives the period and phase, and includes an external enable directingthe top level diagram to execute, which starts the loop. The loop thenprovides a diagram enable (diag_enab) signal to start the loop and waitsfor a diagram done (diag_done) signal to signify completion of the loop,or the period to expire. Based on the value of the Continue flag, theloop provides a subsequent diag_enab signal or determines that the loophas finished and provides a Done signal to the top level diagram.Although not shown in FIG. 34, the loop control block also provides adiagram clear enable out (diag_clear_enab_out) signal to every node inthe sub-diagram of the While loop. Thus the loop control block outputs adiagram enable (diag_enab) signal that is fed to all of the startingnodes in the diagram within the While loop. The Done signals from theseitems are fed into an AND gate, whose output is provided to enablesubsequent nodes.

The shift register includes a data in, a data out and an enable inputwhich clocks the data in (din) to the data out (dout), and a load whichclocks the initial value into the shift register.

Appendix A is a VHDL description corresponding to the example of FIGS.32-34, wherein the VHDL description was created using the presentinvention.

Component Library

The preferred embodiment of the present invention includes a componentlibrary that is used to aid in converting various primitives or nodes ina graphical program into a hardware description, such as a VHDL sourcefile. The following provides two examples of VHDL components in thiscomponent library, these being components for a While loop and amultiplier function.

1. While Loop Component

Appendix B is a source code listing that comprises a VHDL componentreferred to as whileloop.vhd that the present invention uses when aWhile loop appears on a graphical program or diagram. Whileloop.vhdshows how a While loop in a graphical program is mapped to a statemachine in hardware. It is noted that other control structures such as a“For loop” are similar.

Although the system and method of the present invention has beendescribed in connection with the preferred embodiment, it is notintended to be limited to the specific form set forth herein, but on thecontrary, it is intended to cover such alternatives, modifications, andequivalents, as can be reasonably included within the spirit and scopeof the invention as defined by the appended claims.

1. A computer-implemented method for configuring an instrument toperform measurement functions, wherein the instrument includes aprogrammable hardware element, the method comprising: creating agraphical program, wherein the graphical program implements ameasurement function; thea computer system estimating one or more ofsize and cost of a hardware implementation of the graphical program; andthe computer system displaying one or more of the size and cost of thehardware implementation of the graphical program to a user; generating ahardware description based on at least a portion of the graphicalprogram, wherein the hardware description describes a hardwareimplementation of the at least a portion of the graphical program;configuring the programmable hardware element in the instrumentutilizing the hardware description to produce a configured hardwareelement, wherein the configured hardware element implements a hardwareimplementation of the at least a portion of the graphical program; theinstrument acquiring a signal from an external source after saidconfiguring; and the programmable hardware element in the instrumentexecuting to perform the measurement function on the signal.
 2. Themethod of claim 1, wherein the graphical program comprises a pluralityof elements, the method further comprising: storing a data structureincluding a listing of each of the elements and a corresponding cost ofeach element; wherein said estimating uses said data structure.
 3. Themethod of claim 2, wherein the data structure stores cost in terms ofone or more of gates and time of execution.
 4. The method of claim 1,further comprising: determining if the programmable hardware element hassufficient capacity to implement the graphical program in response tosaid estimating, wherein said determining is performed prior to saidgenerating the hardware description.
 5. The method of claim 4, whereinsaid determining comprises: totaling the amount of gates utilized withregard to each element being used in the graphical program, anddetermining if the programmable hardware element has sufficient capacityto implement the graphical program based on the amount of gates.
 6. Themethod of claim 1, further comprising: determining how fast thegraphical program will execute in the programmable hardware element,wherein said determining is performed prior to said generating thehardware description.
 7. The method of claim 1, further comprising:receiving user input regarding desired execution time of the hardwareimplementation of the graphical program; determining if the hardwareimplementation can execute according to the desired execution time,wherein said determining utilizes the execution times of each of theelements; displaying information to the user indicating whether thegraphical program satisfies user input regarding time of execution. 8.The method of claim 1, further comprising: storing in the memory of thecomputer system a plurality of components, wherein said plurality ofcomponents include a first component of a first type and a secondcomponent of the first type, wherein the first component requires afirst number of gates and wherein the second component requires a secondlarger number of gates; wherein said generating the hardware descriptionincludes selecting either said first component or said second component.9. The method of claim 8, wherein either said first component or saidsecond component is selected based on said estimating.
 10. The method ofclaim 8, further comprising receiving user input indicating desiredexecution information; wherein either said first component or saidsecond component is selected based on said user input.
 11. The method ofclaim 10, wherein said desired execution information includes one ormore of number of gates comprised in the programmable hardware elementand a desired time of execution.
 12. The method of claim 8, furthercomprising: storing in the memory of the computer system a library ofcomponents, wherein said library of components includes slower, lesscomplex versions of components and faster, more complex versions ofcomponents; wherein said generating includes selecting among saidslower, less complex versions of components and said faster, morecomplex versions of components.
 13. The method of claim 1, wherein theinstrument is selected based on one or more of the size and cost of thehardware implementation of the graphical program.
 14. Acomputer-implemented method for configuring an instrument to performmeasurement functions, wherein the instrument includes a programmablehardware element, the method comprising: creating a graphical program,wherein the graphical program implements a measurement function, whereinthe graphical program manipulates one or more hardware resources of theinstrument, wherein said creating includes displaying an indication ofusage of said one or more hardware resources during creation of thegraphical program; generating a hardware description based on at least aportion of the graphical program, wherein the hardware descriptiondescribes a hardware implementation of the at least a portion of thegraphical program; configuring the programmable hardware element in theinstrument utilizing the hardware description to produce a configuredhardware element, wherein the configured hardware element implements ahardware implementation of the at least a portion of the graphicalprogram; the instrument acquiring a signal from an external source aftersaid configuring; the programmable hardware element in the instrumentexecuting to perform the measurement function on the signal, whereinsaid executing includes manipulating one or more of the hardwareresources of the instrument.
 15. The method of claim 14, wherein saidone or more hardware resources comprise non-reusable hardware resources;wherein said displaying an indication of usage of said one or morehardware resources during creation of the graphical program is designedto prevent a user from erroneously re-using said non-reusable hardwareresources.
 16. The method of claim 14, wherein said one or more hardwareresources comprise non-reusable hardware esources; wherein saiddisplaying an indication of usage comprises displaying iconsrepresenting said one or more hardware resources on a palette duringcreation of the graphical program; wherein said icons representing saidone or more hardware resources disappear from said palette as said oneor more hardware resources are used in the graphical program.
 17. Themethod of claim 16, wherein, in said creating the graphical program, theicons representing said one or more hardware resources may be draggedfrom the palette into the graphical program.
 18. The method of claim 14,wherein the one or more hardware resources include one or more of: A/Dconverters, D/A converters, timers, counters, clocks, input channels,output channels, and filters.
 19. A computer-implemented method forconfiguring an instrument to perform measurement functions, wherein theinstrument includes a programmable hardware element, the methodcomprising: creating a graphical program, wherein the graphical programimplements a measurement function, wherein the graphical programmanipulates a non-reusable hardware resource of the instrument aplurality of times, wherein said creating the graphical programincludes: constructing sequencing in the graphical program, wherein saidsequencing prevents the non-reusable hardware resource from being usedsimultaneously within the graphical program; generating a hardwaredescription based on at least a portion of the graphical program,wherein the hardware description describes a hardware implementation ofthe at least a portion of the graphical program; configuring theprogrammable hardware element in the instrument utilizing the hardwaredescription to produce a configured hardware element, wherein theconfigured hardware element implements a hardware implementation of theat least a portion of the graphical program; the instrument acquiring asignal from an external source after said configuring; the programmablehardware element in the instrument executing to perform the measurementfunction on the signal, wherein said executing includes manipulating thenon-reusable resource of the instrument a plurality of times accordingto said sequencing.
 20. The computer-implemented method of claim 19,wherein said constructing sequencing is performed using a sequencestructure.
 21. The method of claim 19, further comprising: exporting atleast a portion of the graphical program into a hardware description,wherein the hardware description describes a hardware implementation ofthe at least a portion of the graphical program; wherein said exportingincludes utilizing at least one multiplexer to multiplex control anddata inputs to the non-reusable hardware resource with signals toguarantee that simultaneous accesses are impossible, as indicated by thesequencing.
 22. A computer-implemented method for configuring aprogrammable hardware element to perform a function, the methodcomprising: creating a graphical program, wherein the graphical programcomprises a plurality of interconnected nodes which visually indicatefunctionality of the program, wherein the graphical program specifies afunction; thea computer system estimating one or more of size and costof a hardware implementation of the graphical program; the computersystem displaying one or more of the size and cost of the hardwareimplementation of the graphical program to a user; generating a hardwaredescription based on at least a portion of the graphical program,wherein the hardware description describes a hardware implementation ofthe at least a portion of the graphical program; and configuring theprogrammable hardware element utilizing the hardware description toproduce a configured programmable hardware element, wherein theconfigured programmable hardware element implements a hardwareimplementation of the at least a portion of the graphical program. 23.The method of claim 22, further comprising: the configured programmablehardware element executing to perform the function.
 24. The method ofclaim 22, wherein the programmable hardware element is comprised in adevice, wherein the device includes an input for receiving a signal; themethod further comprising: the device acquiring a signal from anexternal source after said configuring; and the configured programmablehardware element in the device executing to perform the function usingthe signal.
 25. The method of claim 22, wherein the graphical programcomprises a plurality of elements, the method further comprising:storing a data structure including a listing of each of the elements anda corresponding cost of each element; wherein said estimating uses saiddata structure.
 26. The method of claim 25, wherein the data structurestores cost in terms of one or more of gates and time of execution. 27.The method of claim 22, further comprising: determining if theprogrammable hardware element has sufficient capacity to implement thegraphical program in response to said estimating, wherein saiddetermining is performed prior to said generating the hardwaredescription.
 28. The method of claim 27, wherein said determiningcomprises: totaling the amount of gates utilized with regard to eachelement being used in the graphical program; and determining if theprogrammable hardware element has sufficient capacity to implement thegraphical program based on the amount of gates.
 29. The method of claim22, further comprising: determining how fast the graphical program willexecute in the programmable hardware element, wherein said determiningis performed prior to said generating the hardware description.
 30. Themethod of claim 22, further comprising: receiving user input regardingdesired execution time of the hardware implementation of the graphicalprogram; determining if the hardware implementation can executeaccording to the desired execution time, wherein said determiningutilizes the execution times of each of the elements; displayinginformation to the user indicating whether the graphical programsatisfies the user input regarding time of execution.
 31. The method ofclaim 22, further comprising: storing in the memory of the computersystem a plurality of components, wherein said plurality of componentsinclude a first component of a first type and a second component of thefirst type, wherein the first component requires a first number of gatesand wherein the second component requires a second larger number ofgates; wherein said generating the hardware description includesselecting either said first component or said second component.
 32. Themethod of claim 31, wherein either said first component or said secondcomponent is selected based on said estimating.
 33. The method of claim31, further comprising: receiving user input indicating desiredexecution information; wherein either said first component or saidsecond component is selected based on said user input.
 34. The method ofclaim 33, wherein said desired execution information includes one ormore of number of gates comprised in the programmable hardware elementand a desired time of execution.
 35. The method of claim 31, furthercomprising: storing in the memory of the computer system a library ofcomponents, wherein said library of components includes slower, lesscomplex versions of components and faster, more complex versions ofcomponents; wherein said generating includes selecting among saidslower, less complex versions of components and said faster, morecomplex versions of components.
 36. The method of claim 22, wherein thegraphical program comprises a data flow diagram.
 37. Acomputer-implemented method for configuring a device to perform afunction, wherein the device includes a programmable hardware element,wherein the device also includes one or more hardware resources, themethod comprising: creating a graphical program, wherein the graphicalprogram comprises a plurality of interconnected nodes which visuallyindicate functionality of the program, wherein the graphical programimplements a function, wherein the graphical program manipulates one ormore hardware resources of the device, wherein said creating includesdisplaying an indication of usage of said one or more hardware resourcesduring creation of the graphical program; generating a hardwaredescription based on at least a portion of the graphical program,wherein the hardware description describes a hardware implementation ofthe at least a portion of the graphical program; configuring theprogrammable hardware element in the device utilizing the hardwaredescription to produce a configured programmable hardware element,wherein the configured programmable hardware element implements ahardware implementation of the at least a portion of the graphicalprogram; the device executing, wherein the device executing includes theconfigured programmable hardware element in the device executing toperform the function, wherein said executing includes manipulating oneor more of the hardware resources of the device.
 38. The method of claim37, further comprising: the device acquiring a signal from an externalsource after said configuring; the configured programmable hardwareelement in the device executing to perform the function on the signal,wherein said executing includes manipulating one or more of the hardwareresources of the device.
 39. The method of claim 37, wherein said one ormore hardware resources comprise non-reusable hardware resources;wherein said displaying an indication of usage of said one or morehardware resources during creation of the graphical program is designedto prevent a user from erroneously re-using said non-reusable hardwareresources.
 40. The method of claim 37, wherein said displaying anindication of usage of said one or more hardware resources duringcreation of the graphical program is designed to prevent a user fromcreating the graphical program to use a hardware resource two or moretime simultaneously during execution of the graphical program.
 41. Themethod of claim 37, wherein said displaying an indication of usagecomprises displaying icons representing said one or more hardwareresources on a palette during creation of the graphical program; whereinsaid icons representing said one or more hardware resources disappearfrom said palette as said one or more hardware resources are used in thegraphical program.
 42. The method of claim 37, further comprising:displaying a palette comprising icons representing said one or morehardware resources during creation of the graphical program; wherein, insaid creating the graphical program, the icons representing said one ormore hardware resources may be dragged from the palette into thegraphical program.
 43. The method of claim 37, wherein said displayingan indication of usage comprises displaying icons representing said oneor more hardware resources on a palette during creation of the graphicalprogram; wherein said displaying comprises altering said icons in saidpalette to visually indicate the one or more hardware resources beingused in the graphical program.
 44. The method of claim 37, wherein theone or more hardware resources include one or more of: A/D converters,D/A converters, timers, counters, clocks, input channels, outputchannels, and filters.
 45. The method of claim 37, wherein the graphicalprogram comprises a data flow diagram.
 46. A computer-implemented methodfor configuring a device, wherein the device includes a programmablehardware element, wherein the device also includes at least one hardwareresource, the method comprising: creating a graphical program, whereinthe graphical program implements a function, wherein the graphicalprogram manipulates a first hardware resource of the device a pluralityof times, wherein said creating the graphical program includes:constructing sequencing in the graphical program, wherein saidsequencing prevents the first hardware resource from being used two ormore times simultaneously within the graphical program; generating ahardware description based on at least a portion of the graphicalprogram, wherein the hardware description describes a hardwareimplementation of the at least a portion of the graphical program;configuring the programmable hardware element in the device utilizingthe hardware description to produce a configured programmable hardwareelement, wherein the configured programmable hardware element implementsa hardware implementation of the at least a portion of the graphicalprogram.
 47. The method of claim 46, further comprising: the configuredprogrammable hardware element in the device executing, wherein saidexecuting includes manipulating the first hardware resource of thedevice a plurality of times according to said sequencing.
 48. The methodof claim 46, further comprising: the device acquiring a signal from anexternal source after said configuring; the configured programmablehardware element in the device executing to perform a function on thesignal, wherein said executing includes manipulating the first hardwareresource of the device a plurality of times according to saidsequencing.
 49. The method of claim 46, wherein said generating ahardware description includes utilizing at least one multiplexer tomultiplex control and data inputs to the first hardware resource withsignals to provide that simultaneous accesses are not performed, asindicated by the sequencing.
 50. The method of claim 46, wherein thegraphical program comprises a data flow diagram; and wherein saidconstructing sequencing operates to specify a sequence of execution ofportions of the data flow diagram.
 51. The computer-implemented methodof claim 46, wherein said constructing sequencing is performed using asequence structure.
 52. The computer-implemented method of claim 51,wherein the sequence structure comprises a plurality of frames, whereineach of the frames includes a portion of graphical code that utilizesthe first hardware resource; wherein the sequence structure specifies asequencing of the frames to prevent simultaneous execution of theportions of graphical code comprised within the frames.
 53. Thecomputer-implemented method of claim 51, wherein the graphical programcomprises a data flow diagram; wherein the sequence structure comprisesa plurality of frames, wherein each of the frames includes a portion ofthe data flow diagram that utilizes the first hardware resource; whereinthe sequence structure specifies a sequencing of the frames to preventsimultaneous execution of the portions of the data flow diagramcomprised within the frames.
 54. A memory medium comprising programinstructions for configuring a programmable hardware element to performa function, wherein the memory medium stores a graphical program,wherein the graphical program comprises a plurality of interconnectednodes which visually indicate functionality of the program, wherein thegraphical program specifies a function; wherein the program instructionsare executable to implement: estimating one or more of size and cost ofa hardware implementation of the graphical program; displaying one ormore of the size and cost of the hardware implementation of thegraphical program to a user; generating a hardware description based onat least a portion of the graphical program, wherein the hardwaredescription describes a hardware implementation of the at least aportion of the graphical program; and configuring the programmablehardware element utilizing the hardware description to produce aconfigured programmable hardware element, wherein the configuredprogrammable hardware element implements a hardware implementation ofthe at least a portion of the graphical program.
 55. The memory mediumof claim 54, wherein the configured programmable hardware element isoperable to execute to perform the function.
 56. The memory medium ofclaim 54, wherein the programmable hardware element is comprised in adevice, wherein the device includes an input for receiving a signal;wherein the device is operable to acquire a signal from an externalsource after being configured; and wherein the configured programmablehardware element in the device is operable to execute to perform thefunction using the signal.
 57. The memory medium of claim 54, whereinthe graphical program comprises a plurality of elements; wherein theprogram instructions comprise a data structure including a listing ofeach of the elements and a corresponding cost of each element; whereinsaid estimating uses said data structure.
 58. The memory medium of claim57, wherein the data structure stores cost in terms of one or more ofgates and time of execution.
 59. The memory medium of claim 54, whereinthe program instructions are further executable to implement:determining if the programmable hardware element has sufficient capacityto implement the graphical program in response to said estimating,wherein said determining is performed prior to said generating thehardware description.
 60. The memory medium of claim 59, wherein saiddetermining comprises: totaling the amount of gates utilized with regardto each element being used in the graphical program; and determining ifthe programmable hardware element has sufficient capacity to implementthe graphical program based on the amount of gates.
 61. The memorymedium of claim 54, wherein the program instructions are furtherexecutable to implement: determining how fast the graphical program willexecute in the programmable hardware element, wherein said determiningis performed prior to said generating the hardware description.
 62. Thememory medium of claim 54, wherein the program instructions are furtherexecutable to implement: receiving user input regarding desiredexecution time of the hardware implementation of the graphical program;determining if the hardware implementation can execute according to thedesired execution time, wherein said determining utilizes the executiontimes of each of the elements; displaying information to the userindicating whether the graphical program satisfies the user inputregarding time of execution.
 63. The memory medium of claim 54, whereinthe memory medium stores a plurality of components, wherein saidplurality of components include a first component of a first type and asecond component of the first type, wherein the first component requiresa first number of gates and wherein the second component requires asecond larger number of gates; wherein said generating the hardwaredescription includes selecting either said first component or saidsecond component.
 64. The memory medium of claim 63, wherein either saidfirst component or said second component is selected based on saidestimating.
 65. The memory medium of claim 63, wherein the programinstructions are further executable to implement: receiving user inputindicating desired execution information; wherein either said firstcomponent or said second component is selected based on said user input.66. The memory medium of claim 65, wherein said desired executioninformation includes one or more of number of gates comprised in theprogrammable hardware element and a desired time of execution.
 67. Thememory medium of claim 63, wherein the memory medium stores a library ofcomponents, wherein said library of components includes slower, lesscomplex versions of components and faster, more complex versions ofcomponents; wherein said generating includes selecting among saidslower, less complex versions of components and said faster, morecomplex versions of components.
 68. The memory medium of claim 54,wherein the graphical program comprises a data flow diagram.
 69. Amemory medium comprising program instructions for configuring a deviceto perform a function, wherein the device includes a programmablehardware element, wherein the device also includes one or more hardwareresources, wherein the program instructions are executable to implement:creating a graphical program, wherein the graphical program comprises aplurality of interconnected nodes which visually indicate functionalityof the program, wherein the graphical program implements a function,wherein the graphical program manipulates one or more hardware resourcesof the device, wherein said creating includes displaying an indicationof usage of said one or more hardware resources during creation of thegraphical program; generating a hardware description based on at least aportion of the graphical program, wherein the hardware descriptiondescribes a hardware implementation of the at least a portion of thegraphical program; configuring the programmable hardware element in thedevice utilizing the hardware description to produce a configuredprogrammable hardware element, wherein the configured programmablehardware element implements a hardware implementation of the at least aportion of the graphical program.
 70. The memory medium of claim 69,wherein the device is operable to execute, wherein execution of thedevice includes the configured programmable hardware element in thedevice executing to perform the function, wherein during execution theconfigured programmable hardware element manipulates one or more of thehardware resources of the device.
 71. The memory medium of claim 69,wherein said one or more hardware resources comprise non-reusablehardware resources; wherein said displaying an indication of usage ofsaid one or more hardware resources during creation of the graphicalprogram is designed to prevent a user from erroneously re-using saidnon-reusable hardware resources.
 72. The memory medium of claim 69,wherein said displaying an indication of usage of said one or morehardware resources during creation of the graphical program is designedto prevent a user from configuring the graphical program tosimultaneously accessing a hardware resource from two or more locationsin the graphical program.
 73. The memory medium of claim 69, whereinsaid displaying an indication of usage comprises displaying iconsrepresenting said one or more hardware resources on a palette duringcreation of the graphical program; wherein said icons representing saidone or more hardware resources disappear from said palette as said oneor more hardware resources are used in the graphical program.
 74. Thememory medium of claim 73, wherein, in said creating the graphicalprogram, the icons representing said one or more hardware resources maybe dragged from the palette into the graphical program.
 75. The memorymedium of claim 69, wherein said displaying an indication of usagecomprises displaying icons representing said one or more hardwareresources on a palette during creation of the graphical program; whereinsaid displaying comprises altering said icons in said palette tovisually indicate the one or more hardware resources being used in thegraphical program.
 76. The memory medium of claim 69, wherein theprogram instructions are further executable to implement: displaying apalette comprising icons representing said one or more hardwareresources during creation of the graphical program; wherein, in saidcreating the graphical program, the icons representing said one or morehardware resources may be dragged from the palette into the graphicalprogram.
 77. The memory medium of claim 69, wherein the one or morehardware resources include one or more of: A/D converters, D/Aconverters, timers, counters, clocks, input channels, output channels,and filters.
 78. The memory medium of claim 69, wherein the graphicalprogram comprises a data flow diagram.
 79. A memory medium comprisingprogram instructions for configuring a device, wherein the deviceincludes a programmable hardware element, wherein the device alsoincludes at least one hardware resource, the memory medium comprising:creating a graphical program, wherein the graphical program implements afunction, wherein the graphical program manipulates a first hardwareresource of the device a plurality of times, wherein said creating thegraphical program includes: constructing sequencing in the graphicalprogram, wherein said sequencing prevents the first hardware resourcefrom being used two or more times simultaneously within the graphicalprogram; generating a hardware description based on at least a portionof the graphical program, wherein the hardware description describes ahardware implementation of the at least a portion of the graphicalprogram; and configuring the programmable hardware element in the deviceutilizing the hardware description to produce a configured programmablehardware element, wherein the configured programmable hardware elementimplements a hardware implementation of the at least a portion of thegraphical program.
 80. The memory medium of claim 79, wherein theconfigured programmable hardware element in the device is executable tomanipulate the first hardware resource of the device a plurality oftimes according to said sequencing.
 81. The memory medium of claim 79,wherein the device is operable to acquire a signal from an externalsource after said configuring; wherein the configured programmablehardware element in the device is executable to perform a function onthe signal, wherein said executing includes manipulating the firsthardware resource of the device a plurality of times according to saidsequencing.
 82. The memory medium of claim 79, wherein the graphicalprogram comprises a data flow diagram.
 83. The memory medium of claim82, wherein said constructing sequencing operates to specify a sequenceof execution of portions of the data flow diagram.
 84. Thecomputer-implemented memory medium of claim 79, wherein saidconstructing sequencing is performed using a sequence structure.
 85. Thecomputer-implemented memory medium of claim 84, wherein the sequencestructure comprises a plurality of frames, wherein each of the framesincludes a portion of graphical code that utilizes the first hardwareresource; wherein the sequence structure specifies a sequencing of theframes to prevent simultaneous execution of the portions of graphicalcode comprised within the frames.
 86. The computer-implemented memorymedium of claim 84, wherein the graphical program comprises a data flowdiagram; wherein said constructing sequencing is performed using asequence structure, wherein the sequence structure comprises a pluralityof frames, wherein each of the frames includes a portion of the dataflow diagram that utilizes the first hardware resource; wherein thesequence structure specifies a sequencing of the frames to preventsimultaneous execution of the portions of the data flow diagramcomprised within the frames.
 87. The memory medium of claim 79, whereinsaid generating a hardware description includes utilizing at least onemultiplexer to multiplex control and data inputs to the first hardwareresource with signals to provide that simultaneous accesses are notperformed, as indicated by the sequencing.